We love when AI works. It feels almost magical. Like you’ve got superpowers. But it's also maddening. There’s so much prompt-and-hope. So much copy-paste. So much time spent repeating ourselves. It’s just too hard to use it for most of our work. And even harder across a team.

For folks that have figured out how to use it effectively, AI is making us better at doing our own work. But we’re still the ones doing it. Every prompt, every message, every tweak. What we really want is AI that can do work for us, the way we would have done it.

What’s missing isn’t better AI. It’s a better way to work with AI. So we built HappyHQ.

AI You Can Teach

HappyHQ is built around a simple idea: you can teach AI how you do anything. This works just like you would teach a teammate.

Take some part of your workday. Something you do routinely, or something you spend way too much time on. You teach HappyHQ how you want it done. What matters. What good looks like. HappyHQ learns everything it can about exactly how you do this work. Then it does the work for you.

For some folks this might be a statement of work. For others it's user stories, meeting prep, client reports, weekly updates. Whatever your work is, if you can explain it, you can teach HappyHQ how to do it.

This works even when your work is messy. Especially when your work is messy. All the 'it depends' and 'well for this client we do X' and 'except on Fridays.' HappyHQ handles it.

Instead of doing the work yourself, your time is spent managing the work. Reviewing it. Improving it. Teaching HappyHQ how to do it better. Then it keeps doing the work for you. Every time, just the way you want it done.

Here’s the best part: everything you teach HappyHQ is yours. Not hidden in some mysterious memory. The learnings, the instructions, the examples, the way you like things done. That all belongs to you. All stored locally in simple files you can see, read, and edit yourself. We think your work should be yours.

We built HappyHQ for people like us. We’re two founders trying to ship a product, build a brand, write blog posts, keep up with docs, talk with customers, and do everything well while running out of hours in the day. We needed something that could actually take work off our plate. Not a chatbot. Something we could genuinely hand work to and trust the results.

HappyHQ is proudly open source. You can run it yourself. You can bring your own AI accounts. You can even build on top of it. Everything is open, local, and yours by default.

Come Say Hello

HappyHQ is a small, bootstrapped company based in Southern California. We're builders who believe work should be simpler and that the tools you rely on should feel like they were built for you.

The code is open and the work is just getting started. Right now we're onboarding a small number of early users. If you've got a piece of work you'd like to try on HappyHQ, we'd love to hear from you. Sign up to the waitlist for early access or drop us a note at hello@happyhq.com. Developers who want to poke around, contribute, or build on top of it can find everything on GitHub.

It’s your work, your way. Learn more at happyhq.com.

Your team's knowledge: the decisions, the docs, the conversations, and the institutional memory, live in someone else's house. You're renting. You've handed over the keys. And most of the time, you don't even notice, because the rent feels cheap and the house looks nice.

Until it doesn't.

Until the pricing changes. Until the export is broken. Until the feature you relied on gets deprecated. Until you realize you can't actually leave, because leaving means losing everything you built.

This is the world of walled gardens. And it's the world HappyHQ was built to push back against.

We call our approach OLY: Open, Local, Yours. It's not just a feature set. It's a set of beliefs about what software should be and what it should never be allowed to do to you.

O is for Open

Our codebase is open source. This is a non-negotiable.

We chose an MIT License because we believe in the most permissive form of openness. You can read the code. You can audit it. You can fork it, run it yourself, and build on top of it. If HappyHQ ever disappears or makes a decision you disagree with, you are not stranded.

This matters more than ever right now.

We are living through a moment of unprecedented consolidation in the software industry. A handful of companies own the productivity layer of the modern economy. These are not bad companies. Many of their products are genuinely excellent. But they share a common architecture of control. The more embedded you become, the harder it is to leave, and the more you pay.

Open source is the antidote. Not because open source is automatically better software, but because it structurally cannot trap you. The code is there. The community is there. The optionality is yours.

When we say HappyHQ is open, we mean you can trust it in a way you fundamentally cannot trust a closed-source system. With closed software, you are trusting a company's intentions. With open software, you can verify them.

Beliefs:

• Software you cannot inspect is software you cannot fully trust.
• Transparency in code is a prerequisite for trust in systems.
• The community that forms around open software makes it better, faster, and more honest than any internal team can.
• Proprietary lock-in is a feature for the vendor. It should be treated as a bug by everyone else.

L is for Local

Your files live on your machine, in formats you already own.

This sounds basic. It should be basic. It is, somehow, radical.

Most modern workplace tools store your data in proprietary formats inside their own databases, on their own servers, under their own terms. You have access to it, until you don't. You can export it in formats that are either lossy, laborious to work with, or quietly designed to discourage you from leaving.

HappyHQ takes a different position entirely: your documents, notes, and files live on your filesystem, in open formats like Markdown and plain text. There is no account required to access your own work. No server sitting between you and your files. No proprietary format you have to work around. Just files, on your machine, in formats that belong to you.

This is called local-first software, and we believe it is the right architecture for tools that people depend on.

Local-first means your data works completely offline, not in some degraded read-only mode. It means your files are backed up by whatever backup system you already use. It means your editor of choice, your search tools, your scripts, your workflows can all touch your data directly, because it's just files.

It also means that when you open a document you wrote three years ago, it still opens. Because Markdown will still be Markdown in 2035. Because plain text outlives every format that has ever tried to replace it.

Compare this to what happens when a tool shuts down, pivots, or gets acquired. If you're lucky, you might get an export file that you can migrate to something new, but the norm is that it can't be imported anywhere easily and you're still going to lose half your links. You've seen this story. We all have. The format was proprietary, and you paid the price.

Beliefs:

• Your data should be readable without the app that created it.
• Offline access is a right, not a premium feature.
• Open formats are a form of long-term care for your work.
• If you can't find your files with Finder or Explorer, you don't really own them.

Y is for Yours

Your software should feel like yours.

For most of the last few decades, software was generic by necessity. A company built it. You learned it. You adapted your work to fit its opinions about how work should be done. If it didn't quite fit, you lived with it, because you couldn't change it.

AI has given people something new. Not just intelligence, but agency. The ability to look at a tool and say: this isn’t quite right for how we work. And then to actually do something about it. This isn't a technical revolution reserved for developers. It's a shift in what's possible for anyone who uses software to do their work.

HappyHQ is built for this moment. We want every layer of the product to feel like something you can make your own. That should be true in the way the product feels to use, and in the choices it gives you if you need them.

• Your workflows. Defined by you, for your work. Not by us.
• Your AI. Bring your own AI accounts. Choose your models.
• Your infrastructure. Host it where you want.
• Your code. Read it, fork it, extend it.

The everyday experience of using HappyHQ should reflect the way you want to work. The rhythms that feel natural to your team. The way of doing things that brings out your best work. Not someone else's assumptions baked into the product. Yours.

Beliefs:

• Software should adapt to how you work, not the other way around.
• People should be able to shape their tools, not just use them.
• Great software should be simple to use and open to deeper control when you need it.
• Control is not a premium tier. It is the baseline.

Why Now

We’re not interested in dismissing the tools that got us here. Notion, Confluence, Google Workspace, Microsoft 365, Slack. They helped define how millions of people collaborate, write, share, and communicate. They changed how modern teams work.

They also made trade-offs that were reasonable for their era. Collaboration required centralization. Powerful features required proprietary formats. Keeping teams in sync required cloud-first architectures. Those trade-offs came with a cost: your data lives in the vendor's system, your workflows adapt to their architecture, and leaving gets harder the more successful you are inside it.

We're lucky enough to be building in a moment where better software doesn't require the same trade-offs. AI makes local workflows more capable than ever before. Open formats no longer mean giving up features. The assumptions that shaped the last generation of workplace software are dissolving. What remains is the lock-in. And that part is not something we need to carry forward.

We think the next generation should work differently.

A Closing Note

We built HappyHQ to be the workspace we wanted to use ourselves.

That meant it had to be open, so we could trust it. Local, so we could own it. And yours, because we wanted software that felt like our own too.

OLY is not a marketing tagline. It's a set of constraints we hold ourselves to. If a feature would require locking your data in a proprietary format, we don't build it that way. If a capability would require you to use our AI instead of your own, we find another path. If transparency would make our code less defensible as a moat, we prioritize transparency anyway.

Because we believe software should work for you.

Not the other way around.

HappyHQ is open source (MIT License) and available at github.com/happyhqdotcom. Cloud hosting is coming soon. Build in public. Own your work.

When I sold my company to Mailchimp, one of the more satisfying things was getting to join a fun, bright B2B brand with a storied voice in the world of design. Mailchimp was the leader in creating a cheerful B2B brand. The bright yellow (aka cavendish!), the monkey (Freddie!), and even the offices were filled with color and imagination.

The original idea for HappyHQ was born out of frustration. One of the last things I did before leaving my corporate, public-company job was to lead the annual performance review and calibration process for all of Product and Design. My job was to corral hundreds of performance review slides from managers. Each slide represented an individual and listed out accomplishments and opportunities. Each slide also documented a performance rating. Gathering these slides together was like pulling teeth. Heck, even putting my own slides together was incredibly challenging. I found myself spelunking around calendars, docs, slides, analytics tools, Figma, and beyond, trying to remember what had happened to be able to put together the most compelling information. This wasn’t my first rodeo of doing performance reviews and calibrations, but this last time was especially painful. I will have to write more about that in a future post, but the headline is that I knew that there had to be a better way for individuals, managers, and teams to generate more meaningful digests, and then discussions, of their work.

A few months after leaving that product leadership role, I missed building products and teams. I just enjoy designing, building, and shipping products! I also wanted to experience building in the age of AI. It just seemed too interesting to not participate. I had an urge to build something, and the pain of the performance review process was still fresh in my mind. I started to have conversations with other leaders about their experiences with reviews (quick synopsis: every single person despises the process!). The idea of trying to solve the pain of performance reviews started to take shape, but I knew that in order to solve this problem, it required solving a much bigger problem around how and where information in companies is stored, surfaced, and shared.

I began by drafting a doc that outlined my product and company thoughts, and it quickly ballooned into a fun, free-flowing multi-page document of ideas, including about the brand I wanted to create. I shared it with a few friends to get feedback. The name HappyHQ hadn’t yet surfaced, but I did have the idea to create a fun and colorful brand that was loud and happy, and in fact delightful, to use. I wrote these company principles in my initial doc:

Delightful

We believe products and brands should look great and be fun to use. We’re a B2B app, but designed with a playful consumer experience.

Fun

Our brand is bright and happy. We don’t take ourselves too seriously. The work we do is important, and we do it with a smile on our face.

I started to riff on the word, happy. Happy App and Happy Appy came to mind. I liked how those two rhymed, but I didn’t love being locked into the word “app.” As one does, I would think of a name and then check to see if the domain was available. Call me old school, but I still really wanted to have a .com URL.

I then remembered that Slack’s first domain and social handles were “SlackHQ.” There were other companies that also used the “HQ” for their URLs and social accounts. I liked that the “HQ” of “HappyHQ” could actually be relevant to our product (i.e. this is a product that can help your headquarters to be happy!). I did a quick check to see if HappyHQ.com was available, and although it was taken, it appeared as though I could submit a request to purchase it from the owner. I felt like it was probably a slim chance that I could get it and it would likely be too expensive, but I felt like I had nothing to lose by trying. I submitted a bid via the escrow service. I decided to go with an amount that I felt would gather some attention and separate my bid from the noise, but one that was still within my budget. The next day, I got a counter bid that exceeded my budget. It wasn’t too astronomical, but it was still out of my reach. I decided to counter with a final offer that was nearly at my budget, but we were still thousands of dollars apart. At that point, I felt like it wasn’t going to happen. Then, a day later, I got an email from someone at the escrow service with a request from the seller. The seller was asking what I was planning to do with the domain. The person at the escrow service made it clear that I was under no obligation to reply and that my reply would be anonymous. Again, I figured why not try, so I wrote this:

We are building a product to help managers and teams be more intentional and effective leaders. The general thesis is that managers today are poorly equipped to manage people. They don’t have the tools or skill sets to help their employees learn and grow. They are often thrown into the deep end and expected to navigate all the complexities of people management. Our product aims to help managers build engaged and high-performing teams, inspire winning cultures, and in turn, make companies more successful.

One of our founding principles is that we believe that work done well can make people more happy, businesses more successful, and the world more peaceful. (We know, it’s ambitious!) We are a small team of 3 and are completely bootstrapped (i.e. we’re using our savings to build our product!). We love the name HappyHQ. The domain cost is a bit outside of our budget, but we love it so much that we wanted to see if we could get it. We have other domain and naming options, but HappyHQ is our favorite. Thanks, again, for considering.

I sent it off still thinking that my chances of getting the domain were slim, but the very next day I got a note from the escrow service saying, “Congratulations, the seller has accepted your offer.” I was ecstatic! The seller met my counter (going lower than what they had first countered!). At that moment, I just knew that HappyHQ was meant to be!

It’s now about six months later. We’ve incorporated as a C-corporation. We’ve held a few product brainstorming sessions, and we’ve launched an initial splash page with some details about our product and company. We’ve spoken to more potential customers, and we are now working to get an early version of our product launched. Oh, and our first brand workshop is scheduled for next month! I can’t wait to see HappyHQ come to life! I know it’s going to be, and look, fun.

Searching my Google Drive for "book" is a nightmare — four different folders, each packed with countless drafts. My email inbox? Even worse. And don't even get me started on my chat messages — total disaster.

This mess isn’t just my book project; it’s how work feels for most of us these days. Everything’s scattered. Docs and messages are everywhere. Finding the "final" version? Good luck. Half the time, you're not even sure if there is a final version.

Work is happening everywhere and nowhere.

Remember When Slack and Notion Felt Exciting?

I still remember the first time I used Slack and Notion — they felt like a breath of fresh air. Slack’s bright, punchy design and Notion’s sleek interface and clever features felt like magic. Suddenly, working together felt faster, lighter, and way more fun.

Slack saved us from endless email chains, turning those painful back-and-forths into quick, easy chats. Notion replaced those clunky, outdated knowledge systems that no one actually wanted to use. It was like stepping out of a fog.

But here’s the thing: those gains came at a cost. As sharing and creating content became easier, the sheer volume of stuff exploded. More messages. More docs. More noise. Finding the important stuff — the signal in the noise — became a whole new struggle.

Ask anyone what they dislike about Slack or Notion and you’ll probably hear, “It’s too noisy!” or “I can never find anything!”

The Rise of "The Snoop"

We’ve all worked with a "snoop" — you know, the person who is in every channel, reading every message, reacting with emojis left and right. They don’t need to be there, but they can’t resist. With remote work becoming the norm, people are desperate for a sense of connection — a virtual watercooler — so they jump into conversations they don’t really need to follow. It’s understandable, but exhausting. That constant stream of notifications? It’s a dopamine hit that keeps us all on edge.

Here’s the core problem. Our tools today reward this snoop-like behavior with constant alerts, notifications, and emails telling us there is something new and shiny. Our tools haven’t adapted to hybrid or fully distributed work. Our tools haven’t smartly accommodated teams working across time zones. Our tools were created before the proliferation of AI, which when used smartly, can help to surface, summarize, and present the right content to the right people at the right time. Our tools, like Slack and Notion, are still stuck in an office working a 9-5 job. It’s like they are still operating pre-internet, pre-mobile, pre-cloud, pre-AI…and now we need to move to the post-internet, post-office, post-AI world and truly adapt to the future of work.

From Game-Changer to Distraction Machines

Slack is now over a decade old, owned by Salesforce, and still central to most people’s workday. Notion, with its $300+ million in funding, is racing (alongside Slack, Zoom, and others) to become an all-in-one workspace with calendars, productivity tools, and AI features.

But what once felt refreshing now feels overwhelming. These tools have become distraction machines — endless streams of pings and posts that keep us glued to our screens. They make it far too easy to confuse motion with progress. You feel productive bouncing between a dozen channels, but when the day ends, what have you really accomplished?

Meanwhile, finding that one important Notion page or Slack message? Good luck digging through the maze of docs and chats.

We’re Desperate for Something Better

The truth is, we're all craving a different way to work — something lightweight, simple, and yes, still fun. We want a tool that encourages people to share complete thoughts, reducing noise and boosting clarity. We want something that supports makers as much as managers — a tool that helps us stay in flow and cuts down on all the context-switching.

We’re looking for something that keeps information centralized — not yet another app that just creates more silos.

Imagine a tool that smartly blends everything — chat, calls, notes, images, videos, spreadsheets — into one seamless space. Think of a kind of intelligent work journal for yourself and your teams. No more copying and pasting just to keep things connected. No more spelunking through archives to find what’s relevant. A tool that smartly uses AI rather than bolting it on in an intrusive chat interface that they want to charge us more money to use.

Discussions and chats will still exist but it should be a quick escape hatch — a place for fast ideas and questions, not where company announcements, project work, or project updates go to die.

What’s Next?

We believe the future isn’t just "another Slack" or "another Notion." We believe content can be smarter, and collaboration can be calmer — more focused, less frantic.

That’s what we’re building at HappyHQ. We’re not trying to clone Slack or Notion — we’re doing something different, and we’re doing it as a calm company powered by our experience and our customers. We are not being forced to add unnecessary features at all costs because we have investors or shareholders who are demanding growth. We’re focused on solving these issues because we’ve experienced the pain ourselves. If you’re curious about what’s next in work tools, we’d love to show you what we’ve made.

Drop us a note (this will go straight to my inbox!) if you're ready to move past the noise and try something fresh.

I am also regularly trying new techniques to prevent myself from scrolling or, better yet, from even picking up my phone. I have used time limits on certain apps. I have removed certain apps from my phone. I have moved my phone away from my bedroom. I have changed my phone to grayscale mode. I have placed blocks of “focus time” on my calendar. I have done “Digital Sabbaths” where I forgo technology for a day or more. I’m sure there are other techniques I’ve tried but have now forgotten. I know that my phone and the apps on it are purposefully trying to engage me, which is why I’m constantly trying to form different habits and to learn more about what causes me to engage, so I can make improvements.

In the age of infinite scrolling, dopamine-driven Slack notifications, and back-to-back video calls, attention has become one of the most precious and scarce resources. Welcome to the Distraction Economy, where countless devices, apps, and companies compete not just for your wallet and time, but for the very moments between your thoughts.

The Business of Distraction

It’s no accident that our attention spans have been steadily declining. In fact, it’s by design.

Tech apps and platforms, news outlets, and entertainment companies thrive on engagement, which is measured in clicks, views, likes, and watch time. Their algorithms are engineered to hook us, keep us, and pull us back the moment we drift away. The more fragmented our attention, the more opportunities they have to monetize it.

In this economy, our distraction is their revenue. Our attention is the product.

The Hidden Cost of Interruptions

It’s easy to dismiss a quick glance at our phone or a 3-minute scroll through TikTok as harmless, but the research tells a different story. The real cost of distraction isn’t in the interruption itself, it’s in the recovery.

Studies show it can take up to 23 minutes to fully refocus after a single interruption. That’s 23 minutes of diminished creativity, slower thinking, and shallow work. Multiply that by the dozens of distractions we experience daily, and it’s no wonder we end our days feeling scattered and unproductive.

For knowledge workers, this cost is especially high. Deep work, which is the kind of work that solves complex problems, sparks innovation, or produces meaningful writing, requires long stretches of uninterrupted focus. And yet, our tools and environments are increasingly hostile to that very thing.

The Shrinking Attention Span

You’ve probably heard the infamous statistic: the average human attention span is now shorter than that of a goldfish. While the comparison is more myth than science, the trend is real. Studies suggest our sustained attention, defined as the ability to concentrate on a single task without switching, is declining.

Why? Because we’re constantly reinforcing the habit of switching. Each notification, tab change, and mental context shift rewires our brains to seek novelty over depth. And the more we train our brains to jump, the harder it becomes to sit still with anything longer than a tweet or Slack message.

The New Superpower: Intentional Focus

In a world addicted to distraction, focus is our competitive advantage.

The people who will thrive in this new economy aren’t the most connected, but the most intentional. They’re the ones who can protect their attention, design their days around deep work, and resist the siren call of their devices.

This isn’t just about productivity—it’s about reclaiming your agency. Every time you choose to stay present, you’re choosing what kind of life you want to live, and what kind of work you want to create.

Reclaiming Your Attention

So how do we fight back against the distraction economy? I shared some of the techniques that I’ve tried earlier in this post, and here are a few more small but powerful steps:

• Turn off non-essential notifications. Every buzz is a tax on our focus. I have disabled all non-essential push notifications and alerts (yes, even the little red bubble notifications that appear in the corner of an app on the dock of my laptop or browser tab when there is a new message!). My phone is always in silent, focus mode.

• Schedule distraction-free blocks. Give yourself time each day for deep, uninterrupted work. Place blocks on your calendar, put your phone in a different location, and even try creating a new user on your computer that has limited access to apps and logging in as that user.

• Use tools that support focus. There are numerous apps and built-in solutions on most phones and computers that can help you to succeed. A simple search for “apps to help with focus” will give you a bunch of starting points. There are also minimalist browsers that can help reduce temptation. And, cough, cough, you should check out HappyHQ!

• Relearn boredom. Not every idle moment needs to be filled. Some of our best ideas emerge when we’re not actively “consuming.” Try working from a coffee shop, reading in a park, or switching your location in your office or home. Sometimes a new environment can help to regain perspective and focus.

HappyHQ Supports Deep Focus with “Pull” Notifications

We’re building HappyHQ to support deep, focused, and smart work. The future of work doesn’t need to destroy us. Users don’t need to receive every notification or snoop around in every channel, and our docs and pages don’t need to get lost and buried. We’re building a calm app to support calm work.

For us, that looks like:

• Pull, don’t push: We believe in “pull notifications” rather than “push notifications.” This means that it is up to you to decide how and when you want to Subscribe to and receive information. With HappyHQ, we don’t blast alerts or enable any kinds of notifications by default.
• Digests for proactive information sharing: We have Digests that can automagically run on a cadence that you define so you can consume and share information on your terms.
• Streams to easily collaborate on what matters: Streams are the heart of HappyHQ. They are where AI and work merge. Streams get smarter as they go, learning from your patterns and needs. Streams do AI, so you don’t have to do AI.
• Focused discussions that aren’t buried: We know that Discussions aren’t meant to be never-ending affairs between an ever-growing list of participants that are buried deep in channels, threads, and docs that can never be found again. Instead, Discussions on HappyHQ are focused, time bound, contained, and memorialized for easy discovery.

In the past five years, the world has shifted toward distributed-styles of work with fully remote and hybrid work (e.g. splitting time between working from home and working from an office) gaining popularity and adoption. Even companies that have returned full time to an office require tools that support calm, asynchronous work. For example, users need to be able to work away from their offices in the morning, or when they are commuting on a train, or in the evening.

The future of work is distributed regardless of a company's return to office policies, and the future of work requires products that support deep focus and smart learning, but our tools are still stuck in the pre-AI era with outdated SaaS pricing models and death-by-thousands of interruptions and notifications. We deserve and demand better.

The Value of Attention

The attention wars aren’t going anywhere. But we don’t have to be passive participants. The more we recognize the cost of distraction, and more importantly, the value of attention, the better we can navigate the modern world with clarity, creativity, and purpose.

Because in the end, how we spend our attention is how we spend our lives.

Reading List

Here are some of my favorite books on focus and concentration:

Irresistible: The Rise of Addictive Technology and the Business of Keeping Us Hooked by Alter, Adam. Explores the addictive nature of technology and its impact on attention.

Hyperfocus by Bailey, Chris. Offers practical strategies for managing attention and maximizing productivity in a distracted world.

The Shallows: What the Internet Is Doing to Our Brains by Carr, Nicholas. Discusses how digital media is changing the way we think and focus.

Atomic Habits by Clear, James. While primarily about habits, it offers useful insights into building routines that support better focus.

The Power of Focus by Canfield, Jack. Focuses on actionable steps to improve focus in business and life.

Indistractable by Eyal, Nir. Provides a framework for overcoming distractions and regaining control of your attention.

Focus: The Hidden Driver of Excellence by Goleman, Daniel. Explores the science of attention and its impact on performance and well-being.

Stolen Focus: Why You Can’t Pay Attention-and How to Think Deeply Again by Hari, Johann. Investigates why our ability to focus is eroding and what we can do about it.

The Sirens’ Call: How Attention Became the World’s Most Endangered Resource by Hayes, Chris. A recent release on how the battle for our attention shapes society.

Ten Arguments for Deleting Your Social Media Accounts Right Now by Lanier, Jaron. Makes the case for quitting social media to reclaim your mind.

Essentialism: The Disciplined Pursuit of Less by McKeown, Greg. Teaches how to prioritize and focus on what truly matters.

Deep Work by Newport, Cal. Explains how to cultivate deep, distraction-free concentration for meaningful productivity.

Digital Minimalism: Choosing a Focused Life in a Noisy World by Newport, Cal. Offers practical strategies for reducing digital distractions and regaining control.

How to Do Nothing: Resisting the Attention Economy by Odell, Jenny. Explores ways to reclaim your focus in an age of constant digital distraction.

Your Brain at Work by Rock, David. Discusses how to optimize focus and productivity by understanding how the brain works under pressure.

The Attention Merchants: The Epic Scramble to Get Inside Our Heads by Wu, Tim. Examines how businesses compete for our attention and its societal consequences.

The Age of Surveillance Capitalism by Zuboff, Shoshana. Analyzes how tech companies monetize attention and personal data.

Before I go into the many challenges of performance management, I need to detour into some employment law. Bear with me.

Performance Management is Not for Employees, it’s for Employers

The most important thing to understand about performance management is that it isn’t for employees, it is for employers. It is legal Cover Your A$$ (CYA) theater, or as I like to say, capitalism gonna capitalism. Employers enforce performance management on everyone to justify that they are “doing the right thing” for their employees by trying to have clear performance criteria and processes. What they’re really doing though, is documenting employee performance, which can serve as evidence to defend against claims of wrongful termination, discrimination, or unfair treatment, particularly when making decisions regarding promotions, demotions, or terminations. Performance evaluations are essentially providing a legal basis for employment actions by demonstrating, or trying to demonstrate, consistent and fair treatment of employees, as well as showing clear performance expectations and providing a record of feedback given to employees.

The Broken Part

At my large, public company, I was responsible for leading several hundred people through the process. I’ve also done performance management at small startups where the legal liability and formality is less. While the details and surrounding processes were quite different, what was similar is that employees were eager to have real and meaningful conversations about their progress and their careers, while employers were eager to not get sued. What sucked at my last job left a lasting imprint.

At the start of the business year, the company kicked off the performance management process. Employers and employees were both supposed to draft goals, most of them company-specific but some also included personal development. There was a big push by HR around training, communication, and documentation. A huge challenge with this process was that the company goals often weren’t established or, if they were, they weren’t final. This meant that employees were expected to create their personal goals when there weren’t even company goals. That’s a major problem. It’s like starting a trip without knowing where you’re going.

As employees worked on their goals, managers were supposed to be reviewing them and providing feedback. These things rarely happened consistently. After goals were submitted, there was an expectation that the manager and employee would be having ongoing 1:1 meetings to review, discuss, and track progress. At the mid-year mark of the company year, there was an official, company-encouraged check-in process where employees would first write a self review, their manager would then write their review, and then they’d meet to discuss a mid-year rating. Since it was so difficult to easily track any actual process, and referenceable documentation was often lacking, lots of folks had to go back to their calendar, email, laptop, or document repository to try to remember and document what had happened. Nothing about doing all this was easy, satisfying, or uplifting.

At the end-of-year review, this same, clunky performance management process happened again, but this time the rating was formally recorded and had much more impact. Ratings greatly impacted bonus allocations, Performance Improvement Plans (PIPs), and eventual termination, if necessary. This was also the time when managers got to see other team’s ratings, which prompted days and days of meetings where managers discussed the ratings for their direct reports, and those ratings began to change as managers compared (err, I mean, calibrated) their people against other manager’s people. These meetings also usually impacted org chart design and headcount allocations, so they were super important and, often, incredibly biased.

What You Can do to Turn Your Performance Management Experience Into Something Meaningful

Now that we have that high-level, legal-mumbo-jumbo and the time-sucking process overview out of the way, you might be feeling a bit of doom and gloom. I certainly feel your pain. But there’s room to also have hope. Let me start off by reminding you that companies are not families. Companies are entities that conduct business and create jobs. Companies hire employees to achieve goals and, ideally, make more money. You can join and leave companies, companies can hire and fire you. No matter what your relationship is to your family, whether you are super close or somewhat distant, you are still related to each other. While companies aren’t families, they are places where meaningful relationships and connections can be developed.

I’ve now spoken to hundreds of leaders and managers, many of whom I consider to be the best, most thoughtful, empathic leaders in the industry. They all recognize that performance management is an important part of the management toolkit. Yes, these practices exist mainly to protect the company, but they can also protect and help you, as a manager and employee. Additionally, done well, these tools can be incredibly valuable: they can lift up employees in their careers, and challenge and guide them in their career growth. And that’s because communicating clearly and having documented expectations for employees is just good practice. Having clear performance standards by ensuring performance expectations are clearly defined and communicated to employees is not just a good thing for companies to do, it’s actually very good for managers to have these standards in place. Then, using measurable and objective criteria to evaluate performance, will help to avoid subjective biases. There’s also value in providing ongoing feedback to employees (not just throughout the performance period, but ongoing during regular 1:1s). Lastly, maintaining detailed records of performance evaluations, including specific examples of positive and negative performance is not just a good thing to do for the company, it’s incredibly valuable for the employee.

The OG Idea For HappyHQ

After leaving my corporate job, I would often think back to my last experience leading the performance management process and remember just how broken it was. It was like pulling teeth to get managers to do the real and meaningful work of meeting consistently with their teams and writing impactful reviews. I had to go back to my own calendar and documents to remember what had happened throughout the year to be able to put together a coherent self review. It was such a challenge for me, and I know it was for others, too.

I am a big note taker. I love note-taking apps and tools. I also love journaling. I kept thinking and wishing that there was an easier way to journal and track my work. I wanted an app that integrated with my calendar, docs, and other apps to come up with smart digests about my progress. I had the idea for an “intelligent work journal.” In my original product doc for HappyHQ, I wrote:

Managers today have more tools, software, training, and resources than ever before, but are still poorly equipped and prepared to manage people well. They don’t have the tools or skill sets to help their employees learn and grow. They are often thrown into the deep end and expected to navigate all the complexities of people management. Additionally, the actual people management side of a manager's job is often an afterthought when compared to the ever-pressing requirements of meeting urgent business and product needs.

These challenges cascade. Leaders are unable to see or understand how their teams are truly doing. They are flying blind, and even worse, they are being given a false sense of security based on inaccurate information.

I know there has to be a better way to work. As I’ve written in other posts, all of our information is everywhere and nowhere. Our work is buried inside of notes and apps. It’s causing incredible waste, friction, and frustration. HappyHQ aims to be the future of work. We aim to be where work happens, where work isn’t lost or buried, where there aren’t constant interrupts and intrusive notifications, and where you won’t have to go spelunking in your calendar, notebooks, apps, and document archives to figure out what the heck happened over the last year.

We aim to make managing work, tracking it, documenting it and drawing satisfaction from it the happiest experience you’ve ever had. We want to turn the ugh of performance reviews (and much, much more) into a positive tool that works for YOU instead of for lawyers. We can’t wait for you to join us.

*One final legal side note: It's important to state that Europe and many other countries do not conduct management reviews based on these concepts and laws. Employment in Europe is primarily based on formal written contracts that outline the terms and conditions of employment and those contracts outline how any changes in scope need to be handled. I could write an entirely different post about all of this, but that’s not my vibe. I’ll just say that if your company is geographically dispersed, I recommend getting familiar with the employment rules in every country where you operate.

Every now and then, a name sticks.

HappyHQ felt like that from the start. (There’s a great post on the story behind the name, if you’re curious.)

This is also a story about naming, with a twist. These names were never meant to leave our codebase. What started as a routine effort to name internal components turned into something much more useful.

One thing's for sure...we didn't set out to build a distillery.

When we started building HappyHQ, we were focused on helping teams work better together. As founders writing code and debating features, we were just trying to name things clearly so we could stay on the same page and keep shipping.

But somewhere along the way, as we tried to name each part of the system, and make those names fit together, we found a metaphor that just worked. One metaphor led to another. Before we knew it, we had a fully-formed landscape: springs and falls feeding streams, waterwheels turning, and yes, a distillery.

This accidental metaphor quickly became something more valuable—a mental model that brought clarity not just to our code, but to how we think about, talk about, and build HappyHQ. It gave us language people could relate to, something that made the moving parts of the product feel more intuitive.

And now that we have it, we want to share it. Not just because it’s fun to picture (though it kind of is), but because it’s useful. It creates clarity. And if you’ve ever tried naming anything in a layered system, you know how rare that is.

This is the story of how we named our way to a distillery. And a few other things too.

Why naming matters

Naming is how we make sense of the world. It’s one of the first things we do when a child is born. Pets, storms, stars, cities. We name what matters, because names make things easier to communicate.

Think about how we navigate our world through names. We don't say "that celestial body approximately 93 million miles from Earth", we say "the Sun." We don't reference "that body of water between North America and Europe", we say "the Atlantic." Names simplify complexity. They create shared reference points.

In our daily lives, names serve as cognitive shortcuts that make communication possible:

"Meet me at Central Park" works because we all know what "Central Park" means.

"Super Bowl Sunday" immediately communicates both an event and cultural moment

"The Renaissance" captures centuries of cultural evolution in two words.

Without these names, our conversations would collapse under the weight of descriptions and qualifiers. When something lacks a name, it exists in a kind of limbo—fuzzy around the edges, difficult to grasp, nearly impossible to discuss without confusion.

But a name gives it a home. A reference point. A foundation. The moment something has a name, even a temporary one, it gets easier to see, talk about, and build around.

In product development, naming is often treated as an afterthought, something to tackle once the feature is built or when marketing needs a label. This is often a missed opportunity.

Naming isn't just about labeling what you've already created. It's a tool for shaping what you're building while you build it.

Effective names transform how teams think and build:

When Facebook named their internal performance monitoring system Scuba, it wasn’t just clever, it gave engineers a way to imagine diving deep into data, surfacing insights from beneath the noise.

When Airbnb named their animation system Lottie, it transformed a technical tool into something approachable, memorable, and easy to talk about, especially across teams that don’t share the same vocabulary.

When Netflix created Chaos Monkey, they took a sophisticated infrastructure tool and gave it a playful name, one that captured its essence while making it less intimidating and easier to understand.

The right name invites collaboration, reduces friction, and creates clarity. But names don’t just describe what you’ve built, they can shape how you build it.

Call something a "notification configuration module," and it becomes a technical checkbox on a project plan. Call that same feature "Mission Control," and suddenly it's a vital command center demanding thoughtful design.

Even everyday features benefit from clear naming. A feature described as "that area where users can see all their recent activity and what they might have missed" becomes simply "The Feed"—focused, tangible, discussable.

Names aren't just labels. They're foundations for shared understanding. At HappyHQ, this foundation started simply, with a name so intuitive it (eventually) shaped everything that followed.

It all starts with a Stream

Streams aren’t where this naming story begins, but they’re so central to this story that it’s worth starting there.

Streams were always meant to be public. They’re a foundational feature. Users create Streams directly in the UI. And from our earliest conversations, the name just felt right. It clicked. There was something intuitive about it. Something that captured exactly what we were trying to build. We loved the idea of a continually flowing stream. A stream of thought, or even a stream of data.

Sure, Streams are a little like channels on Slack and topics on X, or even threads on Reddit. Creating defined spaces for related ideas is a familiar and effective pattern. It shows up in many of the tools we use today.

But we were drawn to the name "Streams" because it described the behavior we wanted to see from these features. Unlike channels, streams aren't something we expect folks to tune into. They don't need to be watched.

Most collaboration tools today inadvertently create “snoops”—people compulsively checking every channel and thread out of FOMO or a need for information. We’ve all been that person, and we’ve all worked with them. It’s exhausting, but our tools reward this behavior with dopamine-triggering notifications and the pressure to stay current.

Streams offered a better metaphor. In nature, streams don’t demand attention. They invite interaction on your terms. You dip in when you need to cool off or refresh. No pressure to stay immersed. No snoops constantly monitoring every ripple. The stream keeps flowing whether you’re there or not.

That’s exactly what our Streams do—thoughts, data, files, and conversations all flowing through a shared workspace. They’re constantly moving, carrying ideas and information throughout HappyHQ. Not demanding constant attention but always available when needed.

So, we have Streams.

Users can add to those Streams, creating what we call Entries. But then something kind of magical happens behind the scenes: HappyHQ creates Memories from those Entries.

These Memories are visible directly in the Stream. But they also live beyond it, searchable across the workspace, ready to surface and use whenever and wherever they're needed.

But what should we call the critical functionality that takes Entries and turns them into Memories? It wasn't a Stream, an Entry, or a Memory. If anything it was the bridge between them, and it needed a name in our codebase.

We tried simple, descriptive terms: extractor, enricher, parser. Each felt too narrow, too mechanical, or too bland. They also weren't particularly distinctive. We would do each of those things in many different places in our codebase.

We landed on Cortex. It's the part of the brain associated with processing memories, which aligned perfectly with what we were building. We had already been thinking about HappyHQ as a "shared brain" for teams, so Cortex became our digital version of the system humans use to create memories from everyday experiences.

We even wrote this description:

Our memory engine. Inspired by the cerebral cortex in the brain—the region responsible for higher thought and memory. Observes activity in the Streams, and selectively encodes what's meaningful into long-term Memories. Memories are structured, contextual, and durable. They form the basis for everything downstream.

This felt like a strong choice that aligned with what we were building. If we're honest, it was a bit technical, but since this was exclusively an internal name for our codebase we weren't overly concerned.

It wasn't until we needed to name a similar piece of functionality where we started to question whether the Cortex had staying power.

And then came Digests.

Streams are flowing, Memories are being created. Enter the Digest.

Digests are your new best work friend. Or at least, that’s the idea. They help you focus on what matters. They pull meaningful Memories out of the stream and transform them into something timely and useful: a summary, a nudge, an insight. Delivered when and where you need it. No more FOMO. No more scanning every channel, email, or app to figure out what you missed.

But Digests created new naming challenges. There's the digest itself (what users see), how it's defined (the settings), how it's processed (the job), and how its outputs are consumed (the delivery). This created a lot of surface area for confusion. We tried to address it with clearer phrases: "digest instance," "digest definition," "digest job." Technically, this worked, but it felt heavy. Robotic even. Like we were trying to explain dinner with database terminology.

Once again, we needed a name (at least for our codebase). Something for the functionality that powered the engine behind Digests. And we wanted it to sit comfortably next to Cortex in the mental model.

We ended up on Pons, another part of the brain. Here was our initial description:

Our digest engine. The bridge between memory and meaning. Based on the biological pons, which connects the cortex to the rest of the brain and regulates signal flow. Takes Memories from the Cortex (plus system settings, preferences, and other context) and transforms them into structured digest material. Pons is not the digest itself—it's the processor that prepares information to be shared or surfaced. Works quietly but critically, shaping what gets through and how it's framed.

Technically correct. It handled relay and signal. It fit… on paper. But it didn’t feel right. It didn’t explain itself. And it didn’t help the team talk about what it actually did.

While researching the human brain for alternatives to "Pons," we considered names that didn't play as nicely with the Cortex metaphor. We wanted something cohesive, but this was a codebase-only name after all. One of those alternatives was the Distillery. We initially discounted it to maintain a single mental model, but the seed had been planted. And we couldn't shake it.

“Distillery” just worked. Because that’s exactly what a Digest is—a distilled view of what matters, from everything flowing through your workspace. All the raw, messy context gets boiled down into something readable, relevant, and useful.

The realization hit in one of those back-of-mind moments. You know the ones, when you're not actively thinking about a problem, and suddenly the solution just sort of appears. For us that was the marriage of Distillery and Streams. Distilleries are fed by water from streams. That flow is essential to the process. The two concepts weren't just compatible; they were meant to be paired.

A Distillery was immediately practical in a way "Pons" never was. When someone asked "what does this part do?" we could say "it's the Distillery — it takes everything flowing through the Streams and concentrates it into something more valuable." No neuroscience degree required.

“Distillery” wasn’t just a better name. It gave us a new way of seeing the system. And suddenly, the metaphor began to unfold.

Seeing the whole picture

We already had the Stream. Now we had the Distillery, sitting downstream, turning Memories into something more digestible. So we took a step back and looked at the whole system again — through this new lens.

That’s when the next two pieces clicked. We had been talking about "manual versus programmatic sources" for a while. Useful concepts, but awkward phrases that never quite rolled off the tongue. We needed better language and our new landscape made the choice seem rather obvious.

• The Spring for manual input: human-added thoughts, links, uploads. Intentional and direct.
• The Falls for programmatic input: automations, integrations, incoming email, webhooks. Automated, high volume, and always-on.

They both feed the stream. They both scale naturally. And they seemed to capture exactly what makes these two methods different. No more clunky technical phrases. Just a simple, visual model that made immediate sense.

With those pieces in place, the whole scene started to come together. You could actually start to picture it. A Stream cutting across a valley, fed by The Falls and The Spring, flowing toward the Distillery.

It was time to replace the Cortex. Our brain metaphor felt increasingly out of place as our landscape metaphor came to life.

The Cortex's replacement came from actually picturing the scene. We imagined the Stream flowing left to right. The Distillery sitting calmly downstream. And something, some kind of structure, working quietly in the middle.

What sits naturally in a stream? What draws value from the current without interrupting it?

We saw the answer first: a waterwheel.

Waterwheel mills have been turning flowing water into useful outputs for thousands of years. They sit directly in the stream, powered by the current, extracting value without interrupting the flow.

And yes, we liked the alliteration too. The Memory Mill and the Digest Distillery satisfied that part of our brain that craves symmetry.

The Mill felt right on every level. It's powered by the Stream. It doesn't stop the flow—it works with it. And just like a traditional mill turns grain into flour, our Mill turns flowing Streams into structured Memories.

The Cortex was officially out.
The Mill was in, with its waterwheel spinning in the Stream.

The HappyHQ Landscape

We didn't set out to create a landscape, let alone a metaphor. We just needed to name parts of our codebase. But as this landscape took shape it has helped us see the system as a whole. The parts no longer floated in isolation. They connected. And more importantly, it gave us a way to think. Not just about how our system works, but about how it feels.

But for now, we just wanted to show you the HappyHQ landscape that we picture when we close our eyes. We'll dive deeper into each part of the landscape in future posts.

The Falls: Programmatic data cascading from webhooks and integrations, automated and always-on

The Spring: Manual contributions bubbling up from human activity, intentional and thoughtfully placed

The Stream: Where everything converges, carrying ideas and information in perpetual motion

The Mill: Working steadily mid-stream, its waterwheel turning raw content into enriched Memories

The Distillery: Sitting quietly downstream, concentrating what matters most into crystal-clear Digests

If you look closely, you might even spot an owl perched in the trees, quietly observing the whole operation. But we'll save that story for another time.

The power of names

We started this story with a simple truth: names make things easier to communicate. We end it with a deeper one: great names make things easier to understand.

It's easier to talk about a stream than a pipeline. Easier to picture a mill than a memory parser. And much easier to explain a distillery than a digest processor.

The best part? We didn't plan any of this. We just needed names clear enough to keep shipping. But somewhere along the way, those codebase-only names became something more—a shared vocabulary that explains itself. And when a system explains itself, it’s easier to understand, easier to evolve, and easier to believe in.

Now we have more than a system that works. We have a way to talk about what we’re doing — and why it matters. One with a flowing stream, a spinning waterwheel, and a quiet distillery in the valley.

If you're working on something abstract or complex, and you're struggling to talk about parts of it clearly — try finding your stream. See where it flows. And maybe build a little mill of your own.

At HappyHQ’s HQ (which is online, because we’re fully remote!), we are currently doing standups twice a week to sync on key topics and address any blockers on our path to opening up our app to beta customers. In a recent standup, James mentioned the book, Thinking, Fast and Slow by Nobel Prize-winning psychologist Daniel Kahneman. I don’t really remember why he mentioned the book (sorry, James!), but it got me thinking about it again. I love reading books about how our brains work, and this book is one of my favorites. I started thinking about how some of the concepts in the book apply to the future of work, and I thought it would be fun to write a blog post about it.

Here’s that post!

Have you ever wondered why you sometimes make snap decisions that feel spot-on and other times find yourself overthinking even simple choices? I sure have! I have often wondered why some decisions at work feel effortless, while others feel impossibly overwhelming to make. To me, Thinking, Fast and Slow explores exactly that.

Before I explain how it can help us to think about the future of work and the future of collaboration tools, let me first share a brief summary of the book.

A Simple Summary of “Thinking, Fast and Slow”

Thinking, Fast and Slow introduces two systems that shape our decision-making, and it takes us on a deep dive into how our minds work and why we think the way we do. I think it’s the simplicity of these two systems that really captured me when I first read it because they are easy to understand and remember, and they have become helpful tools for me as I work.

Kahneman breaks down our thinking into these two systems:

• System 1: Fast, automatic, and intuitive. This is our “gut instinct” that is always running in the background. It’s the thinking we use to make snap judgments.
• System 2: Slow, deliberate, and analytical. This is the part of our brain that steps in when we need to focus or solve complex problems or make thoughtful decisions.

Both systems are essential, but they can sometimes work against us, and Kahneman’s book is packed with insights on when to trust your instincts and when to pause and think things through. His research revolutionized our understanding of decision making, and, I believe, that his insights are especially relevant in the fast-changing landscape of modern work. As technology advances, remote collaboration becomes the norm, and decision-making cycles speed up, the interplay between these two systems (fast and slow) is more important than ever, but our tools and working cultures mostly reward fast, automatic, and shallow thinking (i.e. System 1 thinking).

Our Brain Loves Shortcuts (But They’re Not Always Right)

System 1 is designed for efficiency. It quickly processes information based on patterns and past experiences. Most of the time, this helps us navigate the world just fine. But sometimes, it leads to cognitive biases or mental shortcuts that can distort our judgment. For example, the availability heuristic tricks you into overestimating the importance of easily recalled information. That’s why dramatic news stories can make rare events (like plane crashes) feel more common than they actually are.

Overconfidence is Sneaky

Kahneman highlights how System 1 can make us feel more confident than we should be. We often trust our instincts even when we lack enough information, which is a classic bias that can lead to poor decisions. When we’re feeling sure about something, we can ask ourselves: What evidence supports this? That simple question can help engage our slower, more thoughtful System 2.

We Value Losses More Than Gains

One of Kahneman’s most famous insights is loss aversion, which is the idea that we feel the pain of losing something more intensely than the pleasure of gaining something of equal value. This explains why people hesitate to take risks, even when the potential rewards are high. When making decisions, recognize when fear of loss may be clouding our judgment. Sometimes playing it safe can cost us opportunities.

First Impressions Are Powerful (But Not Always Accurate)

System 1 jumps to conclusions quickly, which can be helpful, but also dangerous. Whether we’re sizing up a new colleague or reacting to a headline, those first impressions may not tell the whole story. Before acting on a snap judgment, pause and ask: What else might be true here?

How “Thinking, Fast and Slow” Applies to the Future of Work and Some Tips on How I Balance Fast and Slow Thinking

Now that I’ve gotten the book report out of the way, let me shift to trying to explain how Thinking, Fast and Slow connects to the future of work.

The speed of modern work rewards fast, System 1 thinking, and that's risky. Today’s workplace demands quick decisions. Slack pings, constant emails, alerts and notifications galore, and rapid-fire meetings push us to rely on System 1 thinking. While this fast, intuitive thinking is efficient, as I explained above, it’s prone to bias and error. It is ideal for more shallow work, but it becomes a problem when trying to focus on more in-depth problems.

💡 To try to prevent myself from the constant temptations of fast work, I build “pause points” into my routines. Before making key decisions, I often ask myself, “Am I relying on intuition alone, or have I pressure-tested my assumptions?” Before engaging with my inbox and responding to all of the notifications vying for my attention, I also pause. In short, I consciously try to slow down before I engage or when I’m making important decisions.

System 2 thinking thrives in environments that value reflection, data analysis, and deliberate planning. Our tools, which are built by companies who want our attention and want us to spend hours upon hours inside their apps, are distraction machines. They use alerts, notifications, and FOMO to try to get us to engage quickly and stay engaged. But as automation takes over repetitive tasks and as everyone is operating on a surface level, the future of work will increasingly reward those who excel at deep thinking and complex problem solving.

💡One thing I try to do is I purposely carve out dedicated “deep work” time to engage System 2. I put blocks on my calendar for deep, focused work, and I encourage my team to set boundaries, such as silencing notifications, that protect focus time, fostering creativity and better long-term decisions.

Cognitive bias will undermine good decisions if left unchecked. Kahneman highlights common biases like the availability heuristic (overweighting easily recalled information) and confirmation bias (favoring data that supports our beliefs). In fast-moving, System 1 teams, these biases can drive poor decisions.

💡 To help to mitigate some of these biases, I work with my teams to introduce structured decision frameworks to prevent bias. Techniques like the premortem (where teams imagine a project has failed and work backward to identify risks) and decision records (a simple document that outlines the key reasons and research behind a decision) help uncover blind spots before they become costly mistakes.

The future workplace that demands strong collaboration skills and emotional intelligence is the bridge between Systems 1 and 2. Kahneman’s insights reveal that effective leaders are those who balance fast intuition with thoughtful reflection, and that balance requires emotional intelligence.

💡 Doing this requires fostering a culture of psychological safety, where team members feel comfortable challenging ideas and sharing insights. Diverse perspectives slow down snap decisions and improve outcomes. This doesn’t happen overnight. Developing a culture where everyone feels comfortable challenging ideas is possible, but it takes consistent and intentional practice. At HappyHQ, we spend quality in-person time together. Every 6-8 weeks, we meet in person for 2-3 days of connection, food, fun, and games (Rummikub!).

Bringing Kahneman’s Wisdom to Your Team

The future of work won’t reward those who think fast or slow. It will reward those who know when and how to do both. By building awareness of cognitive biases, encouraging deliberate thinking, and creating space for reflection and connection, leaders can guide their teams toward better decisions in a fast-moving world.

Kahneman’s book is a reminder that while speed is essential, thoughtful reflection remains a competitive edge. As you prepare your team for the future of work, ask yourself: Are we thinking fast, slow, or just right? Are our tools and processes rewarding thoughtful reflection?

Kahneman doesn’t suggest we silence our fast-thinking System 1. We’d struggle to get through the day without it, so that would be bad! Instead, the goal is to know when to slow down and let System 2 take the wheel. Here’s a quick way to think about when to use System 1 or System 2:

• Rely on System 1 for routine decisions or situations where speed matters.
• Activate System 2 when stakes are high, emotions are strong, or you’re facing a complex problem.

At HappyHQ, we believe that our work tools should help us with System 1 and System 2 work, and that’s exactly what we’re trying to build. Not everything needs to be delivered now with an alert or notification. Work doesn’t have to destroy us, and our work tools shouldn’t be complicit in this chaos. We believe that work can be calm and efficient, and we know that our tools can help us achieve that. By learning to recognize when your mind’s fast instincts are steering you in the wrong direction, you can make better choices in work, relationships, and everyday life. So the next time you’re about to make a big decision at work by hastily responding to that latest message, by absently replying to that alert or notification, or by quickly commenting on a document, ask yourself: Am I thinking fast or thinking slow? The answer could make all the difference.

Here's a question that seems simple on the surface: What exactly is your product?

If you're like a lot of SaaS startups, you probably think about your product as the application you're building. The thing your customers log into. The thing that solves a problem worth building a company around. We've been there before. It's an easy choice to make. But here's the catch: the product is more than the application you're building. We learned this lesson the hard way, and it has us thinking about things differently as we build HappyHQ.

You're building your first version. What an exciting time! Everyone is heads down trying to breathe life into this idea. It feels a little bit like a race. The faster you get your product out the door, the sooner you'll have customers. The sooner you have customers, the sooner you can do....everything! At least that's how it feels, right? Sure we need a marketing site, but we'll get something basic out the door quickly so we can get back to building our actual product. We can figure out those other things once we have a product customers can use.

Then it happens. Your first real customer is in the pipeline. Everyone becomes focused on closing the deal. On the next call, there is a casual ask for documentation. Everyone panics. We don't have any docs. We can't lose this customer because of...docs. So you do what we've seen countless times - whip up some quick docs just for this customer. It's the fastest option and you know you can provide them exactly what they need. Problem solved! This customer is happy.

But then another customer asks for docs. So you tweak what you made for the first customer. It's faster this time. But now you've got two sets of 'personalized' docs floating around. Both with customer-specific examples, wording, and branding. And just like that, you're accumulating a different kind of debt. Not technical debt—documentation debt. A mess of reactive, one-off documentation that isn't scalable, isn't repeatable, and isn’t part of the product you're building.

Meanwhile, you're still sprinting. Shipping features. Fixing bugs. Reacting to feedback. Then someone asks: "Should we update the marketing site?"

Cue the awkward silence. When was the last time you touched that thing? The site doesn't reflect half of what you've built. The messaging is stale. The product has evolved but the way you talk about it hasn't. You have marketing debt. But your team is focused on the actual product. Who even owns the marketing site? How would you resource a refresh? You're already behind where you thought you would be at this point. Can you afford to take folks off your actual product to work on these other things?

The Better Question (As We Came to Learn) Is Can You Afford Not To?

Your docs, your marketing, and your application are all competing for attention. When we treat the application as our actual product, guess what wins? Every time. But customers need to find your product (through marketing). They need to understand how your product works (through documentation).

It's like IKEA building amazing furniture but having no stores, no website, and no instruction manuals. The furniture might be incredible, but who would know? Who would buy it? Who could build it? IKEA's product isn't just the furniture. It's the entire experience.

What past startups have taught us is these other things aren't really "other things" at all. Your docs, your marketing, and your application should all be products in their own right.

We’re not exactly breaking new ground here. Just look at Stripe—their docs aren’t an afterthought, they’re a product that developers love. And PostHog? Their website isn’t just about selling PostHog—it is PostHog. These companies don’t treat docs and marketing as side projects. They treat them like first-class citizens. Like products. Because they are.

So our thinking started to evolve towards having three separate products at HappyHQ:

1. Marketing: How we tell users our story
2. Documentation: How we educate users
3. Application: How we solve their problems

But something felt off with this approach. We would now have three products. Having one product is hard enough, now we have 3x that. How do we organize around these three products? How much time gets allocated to each one? What wins and loses in a crunch?

If we treat them as separate products, we will immediately be back to making prioritization decisions between them. This may still be an improvement on the status quo, but we're not really solving the root problem. We are recognizing Docs and Marketing as products, but they are still competing with the Application. And in almost every startup, the Application wins.

This reminded us of how software teams used to be structured. Remember when everything was siloed? The Backend Team. The Frontend Team. The Design Team. Infrastructure was... somewhere else. This fragmentation led to a lot of issues. Awkward handoffs. End results that didn't quite work together as a cohesive whole.

Modern software teams fixed this by combining these functions into a single unit - pods, squads, tribes, or whatever you call them. These teams are cross-functional for a reason: the outcomes were better when you brought functions that depend on each other together.

Then it clicked. What if we applied this same thinking to our product?

Instead of having three products, we have one cross-functional product. When we ship features, we're not actually feature complete until it works AND we can (1) tell customers about it and (2) help them get the most value out of it. Marketing, Documentation, and the Application - these are all part of the same product.

This approach started to feel more natural. There are still things to puzzle out, but a startup having one product they can focus on feels like the right foundation. Startups can get back to doing what they do best: relentlessly focusing on the product. The definition of what that product includes has shifted, but the tactics remain the same. Cut out as much as possible. Remove distractions. Ship a product users will love. Will this approach mean startups ship less raw functionality? Probably. But we believe this tradeoff will lead to higher quality, more cohesive experiences for customers. Less, but better.

So how are we planning to make this cross-functional product idea work in practice?

It starts with being intentional. This blog post is actually part of that process. Writing forces clarity - as I was typing this all out, our thinking became sharper. That's one of the reasons why we're committed to building in the open. When your thinking is public, you tend to think more carefully.

But this idea of a cross-functional product only matters if it shapes how we actually build HappyHQ.

That means every feature we ship has to account for all three functions—the product, the docs, and the story we tell about it. Not as an afterthought. Not as a separate step. As part of the way we build.

We're already baking this approach into our workflows and repositories to keep us accountable. This is how our Documentation ReadMe begins:

We've done the whole docs as an afterthought thing before. It doesn't work. We want to be intentional about how we build HappyHQ. That means making docs a core part of our product from Day 0.

Docs drive how we build, how we communicate, and how we make HappyHQ usable—not just for users, but for ourselves. They’re not a side thing. They’re the thing.

Our Documentation principles at HappyHQ:

1. If it's not documented, it doesn't exist.
2. If you build it, you document it.
3. If it changes, the docs change.
4. If a feature can’t be explained clearly, it’s probably not ready.

Great docs don’t slow us down. They make us faster, and our product better.

These aren't just nice-sounding ideas - they're guardrails that keep us honest. That first principle - "If it's not documented, it doesn't exist" - is particularly powerful. It flips the script from "we'll document it later" to "it's not finished until it's documented."

But there's another key element to making this work: creating an environment where the "right choice" is the easy choice. This is what behavioral psychologists call choice architecture.

One of the most famous examples of choice architecture involves middle school lunch lines and the choice between salads and donuts. Where you place options matters just as much as what the options are. Kids pick salad more when it's first in line - not because they suddenly love vegetables, but because the setup makes the healthier choice easier.

I saw this play out during COVID when my family bubbled together in Austin. We had a home gym upstairs - no windows, closed door, basically out of sight. Months went by with no one using it. So one day, I moved the equipment to the back patio where everyone could see it through sliding glass doors. That week, every single person used the gym equipment. Not because they suddenly got motivated, but because we changed the choice architecture. It's not that upstairs was too hard, it's just that it wasn't as easy as it could have been.

This is exactly what we need to apply to our cross-functional product approach. If docs and marketing are truly part of the product, they should live with the product. But most companies split these across different repos:

1. The application repo
2. The docs repo
3. The marketing repo

This setup forces engineers to actively go somewhere else to update docs, then go somewhere else again for marketing. It's technically possible, but we're making our desired approach harder. If we want this cross-functional mindset to stick, we need to make it the path of least resistance.

Enter the monorepo.

(Full disclosure: I'm not an expert on the history of monorepos. They gained popularity for plenty of technical reasons - version control, CI/CD, deployments, and other practical eng reasons. But for our purposes, they also seem to be the perfect solution to our choice architecture challenge.)

The concept is simple: one repository, three directories:

1. www - How we tell users our story
2. docs - How we educate users
3. app - How we solve their problems

This doesn't magically solve all of our problems, but it makes our chosen approach dramatically easier to follow. When an engineer is working on the application locally, they're already inside the same repository that contains the docs and marketing site. They can spin up all three with a single command from a single place.

It's the software equivalent of moving the weights from upstairs to downstairs. We haven't forced anyone to do anything - we've just made the behavior we want more natural. The path between "I should update the docs" and actually doing it is now shorter, more visible, and part of a more fluid workflow.

At HappyHQ, we're all about making intentional choices. We're building a platform to help teams be more intentional about how they communicate and collaborate. Helping reduce noise, avoid distractions, and focus on what matters. But that has to start with us - with how we build HappyHQ itself.

Rethinking our product isn’t just a technical shift. It’s a cultural one. It means every person on our team needs to care about our product as a whole, not just the application. It means redefining what it means to ship. It means celebrating documentation as much as we celebrate new features. This isn't always comfortable - we're fighting against years of ingrained habits. In the startup world, docs and marketing sites are treated a lot like how middle schoolers treat salad. A lot of folks simply don't want to work on them. They're seen as inferior to our actual product.

But we believe a more holistic approach will lead to a better product and a healthier team. We’re betting on the cross-functional product as a way to give our users a more complete, cohesive experience. When the way we tell our story, the way we teach our product, and the way our product works are all aligned, users win. They find us more easily. They understand us more quickly. They get value more consistently.

As we put this to the test, we'll learn what works and what doesn't. Our thinking will evolve, and there will be natural forcing functions that require us to revisit our approach over time. But the underlying goal will stay the same: building a quality experience that feels whole and thoughtful from the first touchpoint to the deepest interaction.

If you've been through something similar or see things differently, we'd love to hear from you.

Happy building!

But First, Why Docs Rock!

We're not anti-docs—seriously! Docs are incredible. One of the earliest and most famous examples, the Rosetta Stone (c. 196 BC), bridged multiple ancient languages to communicate a royal decree. Throughout history, documents like the Magna Carta and the Declaration of Independence have shaped nations. And while not every doc rewrites history, docs are everywhere today—from shopping lists to product specs, ways of working, employee handbooks, and even this blog post.

Nowadays, we have so many great tools for creating and managing docs—Microsoft Word, Google Docs, Notion, Confluence, Obsidian, and even Slack with its new canvas feature. Industry-specific tools would add even more to the list. Writing docs has never been easier. The tools are lightweight, intuitive, and built for seamless collaboration.

A well-written doc can be powerful. It can align teams, build shared understanding, and provide clarity and motivation. But docs have their limits—especially when they’re expected to single-handedly capture everything in your knowledge base. Relying on docs alone puts too much weight on a single format, making knowledge harder to maintain, find, and act on.

Docs Need Their Chat Moment.

Imagine if the only way we could communicate was through email. It has its place, but it’s slower, more formal, and structured by default—salutations, signatures, and formatting. Attaching files works, but it's a bit clunky and awkward. Every email has a defined audience, and looping others in means juggling CCs, replies, forwards and endless nested threads.

Email now feels dated and cumbersome for collaboration. The rise of real-time chat platforms has been a major driver of this shift. While not without its own challenges (more on that in a future post), chat offers a faster, lighter, and easier alternative to email. This shift hasn’t made email obsolete—it’s made it better. By absorbing quick conversations, brainstorming, and real-time collaboration, chat has allowed email to focus on what it does best: structured, intentional communication—often with external audiences. (Now, if only it could shake off all the outbound drip spam.)

The knowledge base needs its own renaissance—but that doesn’t mean abandoning docs. Instead, docs should be one character in an expanded cast. Just as chat helped redefine email’s role, the right complementary tools can make docs more valuable, not less. We’ll explore what that cast might look like a little later. But first, let’s unpack why relying on docs alone is inherently limiting for knowledge bases and the teams that depend on them.

We're Asking Too Much Of Docs.

We think of knowledge bases as the home for everything teams need to know. A single place where shared understanding lives. But today's knowledge bases are built exclusively on docs. And docs, like practically everything else in this world, aren't great at everything.

1. A huge chunk of knowledge never makes it into a doc at all. We have this foundational assumption that all of our knowledge is in our knowledge base. But the reality is, it's not all there. In fact, it's not even close to all there. Roadmaps live in product tools, designs in Figma, decisions in Slack, debates in meetings, ideas in people’s heads. Trying to force all of this into docs is awkward and time-consuming.

2. Docs take too long, so we avoid or rush them. Writing a doc is like writing an email—it takes time. We need to work through a series of decisions. What are we trying to say? What needs to be included? What can we leave out? How should it be structured? Should we use headings? A template? Because docs take time, we either don’t write them at all (and lose knowledge entirely) or we rush through them (and end up with messy, half-baked docs that no one trusts).

3. Docs become a dumping ground for everything. When a doc is the only option, everything becomes a doc—even when it shouldn’t be. Articles to read, raw notes, early ideas, random links—shoved into docs simply because there’s no good alternative. Docs aren’t built for quick thoughts, ongoing discussions, or evolving ideas. But when they're our only medium, things that shouldn't be docs become docs. And when everything becomes a doc, the value of docs deteriorates. It becomes harder to tell what’s important. The signal-to-noise ratio tanks.

4. More docs = worse shared understanding. The more docs we create, the harder it is to find what matters. People can’t tell what’s important, what’s outdated, or where to even start looking. We assume they'll navigate the doc hierarchy a certain way, but in reality they might:

1️⃣ Click a direct link to a doc and never see the surrounding context
2️⃣ Use search, where outdated and irrelevant docs clutter the results
3️⃣ Ignore updates because notifications are too granular

Eventually, the knowledge base turns into a black hole. Someone becomes the de facto knowledge whisperer—the only person on the team who can actually find things.

5. Docs don’t evolve naturally. As docs are drafted, collaboration happens naturally. People contribute and our thinking evolves. But docs tend to follow a linear path from draft to final. A "final" doc captures knowledge at a moment in time, but final feels awkward when applied to most knowledge. And when everything feels final, nothing gets updated. People hesitate to "mess up" someone else's work. So instead of editing, they create a separate version. Now there are two docs with the same purpose. Then another. And another. Instead of a single source of truth, we have a pile of conflicting and outdated docs that are predisposed to becoming stale.

6. Docs are one size fits all. Different people need different information. But docs don’t work that way—they’re one-size-fits-all, which usually means too much information for everyone. Take a product spec. Engineers need technical details. PMs need the big picture. Designers need UX considerations. Customer support needs to know what’s changing for users. Instead of building docs specific to each audience, the doc just gets longer. The more audiences a doc tries to inform, the harder it is for anyone to find what’s relevant to them.

7. Freeform text is one dimensional. We rely on docs for all kinds of information—product specs, announcements, and blog posts. We also use them for things that follow a clear pattern—Q&As, glossaries, step-by-step guides, decisions, risks, and goals. Docs make it easy to write things down, but hard to capture, connect, and organize what matters. We can format text, but text is still just text. That means our docs (and our teams) lack crucial context behind the knowledge being shared. When someone edits the Q1 Goals doc, we have no way of knowing whether they corrected a typo or added a new goal. We also can't easily pull goals from this doc and compare them to last year's. It's all just text.

8. Docs aren't designed for action. Docs are great for capturing knowledge, but bad at helping us use it. Once something is written in a doc, it's up to us to track it down and figure out what to do with it. Take a product roadmap. We document features, priorities, and timelines. But when someone needs a status update, they dig through the docs, ask around, or manually rewrite the same information in a different format. The knowledge exists—it’s just stuck in docs. Writing something down is just the start. Teams need better ways to use this knowledge.

A Knowledge Base Built For Today.

Docs aren’t bad—they just aren't enough on their own.

Most of the problems we've talked about start to disappear when docs are supported by the right cast of characters—each designed to handle a different piece of how teams capture, access, evolve, and use their knowledge.

So what else does a knowledge base need?

Memories. A lighter, faster way to capture and share knowledge without turning it into a doc. Whether it's notes, work from somewhere else in the stack, or something with a little more structure (like a 'Decision'), adding a Memory should feel as easy as sending a message.

Streams. Memories flow into Streams. A simple, familiar way to keep knowledge organized around a topic, project, or event. Streams make it easier to find, share, and add to the knowledge within a team, without running into the side effects of docs.

AI Digests. Imagine if adding to your knowledge base also meant your updates were written for you. Project summaries, weekly trackers, audience-specific updates—all ready to go. AI that works with your knowledge should feel a little magical.

Discussions. Teams need a place to ask questions, share ideas, and work through proposals. Not lost in chat. Not buried in docs. Discussions should have a proper home—one that works alongside Memories, Streams, and everything else in your knowledge base.

Pages. A knowledge base wouldn't be a knowledge base without docs. But the docs that are left should be treated like a scarce resource. Fewer docs means higher-quality docs. And when docs are used intentionally, the important ones stand out.

It's Time For A Rethink.

At the end of the day, this isn't about whether or not to use docs. Docs aren't going anywhere. But with AI opening up new ways to capture and use knowledge, relying solely on docs feels more limiting than ever.

Our teams want to move faster and produce higher quality outcomes—without having to do more work. Making this a reality means rethinking the knowledge base. Teams need more choice. More intentional tools that fit the way they actually work. Whether it’s personal notes, team projects, or company-wide initiatives, working with knowledge shouldn’t feel like a chore.

When knowledge flows freely, everything improves. Teams move faster, stay aligned, and focus on what matters. There's less noise. Fewer distractions. Smoother collaboration. All key ingredients for happy, healthy, high-performing teams.