Signal v. Noise

We had originally planned to release HEY, our new email service, in April. There was the final cycle to finish the features, there was a company meetup planned for the end of the month to celebrate together, we’d been capacity testing extensively, and the first step of a marketing campaign was already under way.

But then the world caught a virus. And suddenly it got pretty hard to stay excited about a brand new product. Not because that product wasn’t exciting, but because its significance was dwarfed by world events.

A lack of excitement, though, you could push through. The prospect of a stressful launch alongside the reality of a stressful life? No.

That’s not because we weren’t ready to work remotely. That we had to scramble to find new habits or tools to be productive. We’ve worked remotely for the past twenty years. We wrote a book on working remotely. Basecamp is a through and through remote company (and an all-in-one toolkit for remote work!).

But what’s going on right now is about more than just whether work can happen, but to which degree it should. We’re fortunate to work in software where the show doesn’t have to stop, like is the case in many other industries, but the show shouldn’t just carry on like nothing happened either.

About half the people who work at Basecamp have kids. They’re all at home now. Finding a new rhythm with remote learning, more cramped quarters, more tension from cooped-up siblings. You can’t put in 100% at work when life asks for 150%. Some things gotta give, and that something, for us, had to be HEY.

And it’s not like life is daisies even if you don’t have kids. This is a really stressful time, and it’s our obligation at Basecamp to help everyone get through that the best we can. Launching a new product in the midst of that just wasn’t the responsible thing to do, so we won’t.

Remember, almost all deadlines are made up. You can change your mind when the world changes around you.

HEY is going to launch when the world’s got a handle on this virus. When we either find a new normal, living within long-running restrictions, or we find a way to beat this thing. We’re not going to put a date on that, because nobody knows when that might be. And we’re not going to pretend that we do either.

In the meantime, we’ll keep making HEY better. We’re also going to put in time to level up Basecamp in a number of significant ways that have long been requested. The work doesn’t stop, it just bends.

If you wrote us an email to [email protected], you’re on the list, and we’ll let that list know as soon as we open up. If you think you might be interested in a better email experience when that’s something we all have the mental space to think about again, please do send us a story about how you feel about email to [email protected].

Stay home, stay safe!

For many, moving from everyone’s-working-from-the-office to everyone’s-working-at-home isn’t so much a transition as it is a scramble. A very how the fuck? moment.

That’s natural. And people need time to figure it out. So if you’re in a leadership position, bake in time. You can’t expect people to hit the ground running when everything’s different. Yes, the scheduled show must go on, but for now it’s live TV and it’s running long. Everything else is bumped out.

This also isn’t a time to try to simulate the office. Working from home is not working from the office. Working remotely is not working locally. Don’t try to make one the other. If you have meetings all day at the office, don’t simply simulate those meetings via video. This is an opportunity not to have those meetings. Write it up instead, disseminate the information that way. Let people absorb it on their own time. Protect their time and attention. Improve the way you communicate.

Ultimately this major upheaval is an opportunity. This is a chance for your company, your teams, and individuals to learn a new skill. Working remotely is a skill. When this is all over, everyone should have a new skill.

Being able to do the same work in a different way is a skill. Being able to take two paths instead of one builds resiliency. Resiliency is a super power. Being more adaptable is valuable.

This is a chance for companies to become more resilient. To build freedom from worry. Freedom from worry that without an office, without those daily meetings, without all that face-to-face that the show can’t go on. Or that it can’t work as well. Get remote right, build this new resiliency, and not only can remote work work, it’ll prove to work better than the way you worked before.

In this livesteam, David and I answer audience questions about how to work remotely. At Basecamp we’ve been working remotely for nearly 20 years, so we have a lot of experience to share. This nearly 2-hour video goes into great detail on a wide variety of topics. Highly recommended if you’re trying to figure out how to work remotely.

David and I spent nearly 2-hours giving a livestream tour of our very own Basecamp account. We wanted to show you how Basecamp uses Basecamp to run projects, communicate internally, share announcements, know what everyone’s working on, build software, keep up socially, and a whole bunch more. Our entire company runs on Basecamp, and this video shows you how.

People are always curious about work-from-home (WFH), remote working setups. So, I posted a Basecamp message asking our employees to share a photo of their home office, desk, table, whatever. Here’s what came in.

First, the ask:

And the answers, in the order they came in:

Keep reading “Remote Working: The home office desks of Basecamp”

Back on June 9, 2018, I cold emailed [email protected]:

Hey there–

Curious… Would you entertain an offer to sell hey.com? I'd like to use it for something I'm working on, and willing to make you a strong offer.

Let me know. Thanks!

-Jason

And that’s where it all began.

For the 25+ years I’ve been emailing, I’d say close to 95% of those email began with some variation of “Hey [Name]”. So when it came time to think about a name for a new email system we’d be building, HEY was a natural.

Further, the “Hey!” menu in Basecamp 3 holds your notifications for new messages, chats, to-do assignments, automatic check-in prompts, boost summaries, and the like. So we already had some prior art on Hey being a place for communication.

But hey.com – that would be an amazing email address, and, we rightly assumed, hard to get. But what the hell – if you don’t ask you don’t get, so I sent the email, crossed my fingers, and waited.

The same day I emailed, June 9, 2018, he replied. Turns out we’d actually talked before on This Week in Tech, way back when. This was his first email back to me:

Hi Jason:

Thanks for reaching out, I've always respected your business accomplishments and your writing. You may not remember but we spoke briefly a couple of times when I was at TWiT.

As you might imagine, I've gotten a number of offers and inquiries about HEY.com over the years. Usually I ignore them, but very happy to chat with you about this or any other topic. I'm on cell at ###-###-####.

Thanks!

Dane

So we set up a call and had a nice chat. Really nice guy. A few days later, I made an offer.

He said no.

So I countered.

He said no.

We were clearly way off. And the momentum went cold. He decided he wasn’t ready to sell. I thanked him for the opportunity and said let’s stay in touch.

Then on August 19, 2019, well over a year after my initial outreach, he wrote me back.

Hi Jason:

Not sure if you're still interested in Hey.com, but I'm in the process of vetting what appears to be a serious inquiry to buy it. The numbers being discussed are notably higher than what you mentioned previously. Given your previous offer I'm thinking you probably won't be interested, but I appreciated your approach and also what you've done for the industry, so I thought I'd let you know as a courtesy.

We caught up via Zoom a few days later, discussed again, and I made another offer. This time significantly higher than our original offer. It was a nervous amount of money.

Things were beginning to heat up, but there was no deal yet. I completely understood – he owned this domain for a long time, and he wasn’t a squatter. Dane used hey.com for his business. It was part of his identity. It was a valuable asset. He needed time to think it through.

We traded a number of other emails, and then I upped the offer a little bit more on September 18, 2019.

A few days later we’d verbally agreed to move forward on an all-cash deal with a number of stipulations, conditions, etc. All were perfectly reasonable, so we asked him to prepare a contract.

There were a few small back and forths, but we essentially accepted his contract and terms as is. We wired the money into escrow, we waited for some Google mail transfer stuff to finish up, and on November 20th, 2019 the domain was officially transferred over into our ownership. Funds were released to escrow, and the deal was done.

This was a long 18 month process, and there was uncertainty at every step. We’d never bought a domain like this, he’d never sold a domain like this. There’s a lot of trust required on all sides. And more than money, hey.com was important to him. And who he sold it to was important to him as well.

But it was truly a pleasure to work with him. Dane was fair, thoughtful, patient, and accommodating. And for that we’re grateful. Business deals like this can get messy, but this one was clean and straightforward. Kudos to him and his lawyer for their diligence and clear communication.

All in we traded 60+ emails over the course of the deal. Toss in a few zoom calls as well.

So that’s the story of how we acquired hey.com. One cold email to kick it off, no domain brokers or middlemen, and a lot of patience and understanding on both sides.

Wait how much was it? I know everyone wants to know, but we can’t say. Both sides are bound by a non-disclosure around the final purchase price. You’ll just have to guess.

As for Dane, he relaunched his brand under a new name. You can check him out at VidiUp.tv.

As for us, this April we’ll be launching our brand new email serviced called HEY at hey.com.

Note: This post was cleared with Dane prior to publishing, so he’s cool with me sharing his name, the story, and the name of his new company.

I’m reviewing transcripts from interviews we did with customers last year and came across a nice example of interview technique.

The hardest thing about customer interviews is knowing where to dig. An effective interview is more like a friendly interrogation. We don’t want to learn what customers think about the product, or what they like or dislike — we want to know what happened and how they chose. What was the chain of cause and effect that made them decide to use Basecamp? To get those answers we can’t just ask surface questions, we have to keep digging back behind the answers to find out what really happened.

Here’s a small example.

Doris (name changed) works in the office at a construction company. She had “looked for a way to have everything [about their projects] compiled in one area” for a long time. All the construction-specific software she tried was too “in depth.” She gave up her search. Some months later, she and her co-worker tried some software outside the construction domain: Monday and Click-Up.

I asked: How did you get to these options?

She said she and her co-worker did Google searches.

I asked: Why start searching again? You tried looking for software a few months before. What happened to make you look again?

She said they had quite a few new employees. And “needed a place for everything to be.”

That sounds reasonable enough. We could have moved on and started talking about how she got to Basecamp. But instead of accepting that answer, I kept digging.

Ok so you hired more employees. Why not just keep doing things the same way?

“It was an outdated system. It’s all paper based. And this isn’t a paper world.”

We have our answer, right? “Paper based” is the problem. No, not yet. That answer doesn’t tell us enough about what to do.

As designers that’s what we need to know. We need to understand the problem enough to actually decide what specifically to build. “Paper based” sounds like a problem, but what does it tell us? If we had to design a software fix for her right now, where would we start? What would we leave out? How would we know when we made the situation better enough to stop and move on to something else?

So I asked one of my favorite questions:

What was happening that showed you the way you were doing things wasn’t working anymore?

This question is extremely targeted and causal. It’s a very simple question that invites her to describe the problem in a way that is hard, factual, time-bound, contextual, and specific — without any analysis, interpretation, speculation or rationalization. Just: What happened. What did you see. What was wrong.

“The guys would just come ask for the same information over and over again. And it was taking up time for me. . . . They shouldn’t have to ask me some of these questions. You get asked 20, 30 stupid questions and try to go back to something you have to pay attention to . . . you’re working numbers and money you need to be paying attention to what you’re doing.”

Aha. Now we’re getting somewhere. She holds all the information. The guys in the field need the information. She needs to give them access to the information so they can look it up themselves. Then she’ll stop getting interrupted and she can focus on her own work.

This dramatically narrows down the supply side and begins to paint the outlines of actionable design requirements.

I check to see if I understand the causality here.

Was the number of interruptions worse after you hired more people?

“Oh yeah, absolutely.”

Because we kept digging for causality, we got to an understanding of the situation — what caused it, what went wrong, what progress meant to her, and why she was saying “yes” and “no” to different options as she evaluated them.

For more on this interview approach I recommend checking out Competing Against Luck by Clay Christensen.

Here are all my extracted answers from our monthly Basecamp check-in question of What are you reading? for 2019. (See also my answers from 2016, 2017, and 2018).

The Sane Society
Another Fromm tome! This one starts from the premise of evaluating the different social characters of various societies. But not from the abstract, pretend objectiveness of “everything is equal; everything is just different”, but from a bold perspective of “some societies truly do better than others at promoting human health and flourish. That’s potentially a dynamite perspective, but Fromm handles it with utter grace and respect.

I particularly enjoyed the concept of mental illness or malaise as an act of rebellion against societal pressures and norms. Particularly the refutation that “the sane person” is whoever is performing their productive function in society. Yeah, fuck that.

I also really liked the depiction of a country’s social character to be an expression of what that society thought it needed. A German reputation for stinginess/savings as virtuous? A reflection of what the country needed in order to rebuild after 20th century devastation. It’s a fascinating recast of “stereotype” as something intellectually productive, and not just lazy othering.

Keep reading “The books I read in 2019”

The internet is finally coming out of its long haze on privacy, but it’s with one hell of a hangover. So many practices that were once taken for granted are now getting a second, more critical look. One of those is the practice of spying on whether recipients of marketing emails open them or not.

Back in August, we vowed to stop using such spying pixels in our Basecamp emails. And do you know what? It’s been fine! Not being able to track open rates, and fret over whether that meant our subject lines weren’t providing just the right HOOK, has actually been a relief.

But whether these open rates are “useful” or not is irrelevant. They’re invasive, they’re extracted without consent, and they break the basic assumptions most people have about email. There’s a general understanding that if you take actions on the internet, like clicking a link or visiting a site, there’s some tracking associated with that. We might not like it, but at least we have a vague understanding of it. Not so with email spy pixels.

Just about every normal person (i.e. someone not working in internet marketing) has been surprised, pissed, or at least dismayed when I tell them about spy pixels in emails. The idea that simply opening an email subjects you to tracking is a completely foreign one to most people.

When I’ve raised this concern in conversations with people in the marketing industry, a lot of them have taken offense to the term “spy pixels”. Affixing the spying label made a lot of them uncomfortable, because they were just trying to help! I get that nobody wants to think of themselves as the bad guy (Eilish not withstanding), but using the word “spy” isn’t exactly a reach.

Here’s the dictionary definition of a spy: “a person who secretly collects and reports information on the activities, movements, and plans”. That fits pretty well to a spy pixel that tracks whether you open an email or not, without your knowledge or consent!

So. Let’s stop doing that. Collectively. And the best place to instigate reform is with the mailing list software we use. A modest proposal for a basic ethics reform:

1) Mailing list software should not have spy pixels turned on by default. This is the most important step, because users will follow the lead of their software. It must be OK to spy on whether people open my marketing emails if the software I’m using it provides that by default.

2) Mailing list software can ask for explicit consent when the sender really does want to track open rates. Let the sender include a disclaimer at the bottom of their email: “[The sender] would like to know when you open this email to help improve their newsletter. If that’s OK with you, [please opt-in to providing read receipts]. Thanks!”.

That’s it. Don’t do it by default, ask for informed consent if you must. Being respectful of someone’s privacy isn’t rocket science.

And remember, you can still tag your links in those emails with ?source=newsletter or whatever to see whether your call-to-action is working. As we discussed, people have a basic understanding that clicking links and visiting websites – explicit actions they take! – has some tracking involved.

This isn’t going to magically make everything better. It’s not going to fix all the issues we have with privacy online or even all the deceptive practices around mailing lists. But it’s going to make things a little better. And if we keep making things a little better, we’ll eventually wake up to a world that’s a lot better.

One of the great tragedies of modern web development over the last five years or so has been the irrational exuberance for microservices. The idea that making a single great web application had simply become too hard, but if we broke that app up into many smaller apps, it’d all be much easier. Turned out, surprise-surprise, that it mostly wasn’t.

As Kelsey Hightower searingly put the fallacy: “We’re gonna break it up and somehow find the engineering discipline we never had in the first place”.

But it’s one of those hard lessons that nobody actually wants to hear. You don’t want to hear that the reason your monolith is a spaghetti monster is because you let it become that way, one commit at the time, due to weak habits, pressurized deadlines, or simply sheer lack of competence. No, what you want to hear is that none of that mess is your fault. That it was simply because of the oppressive monolithic architecture. And that, really, you’re just awesome, and if you take your dirty code and stick it into this new microservices tumbler, it’s going to come out sparking clean, smelling like fucking daffodils.

The great thing about such delusions is that they can keep you warm for quite a while. A yeah, sure, maybe the complexities of your new microservices monstrosity are plain as day right from the get go, but you can always excuse them with “it’s really going to pay off once we…” bullshit. And it’ll work! For a while. Because, who knows? Maybe this is better? But it’s not. And the day you have to really admit its not, you’re probably not even still there. On to the next thing.

Microservices as an architectural gold rush appealed to developers for the same reason TDD appeals to developers: it’s the pseudoscientific promise of a diet. The absolution of a new paradigm to wash away and forgive our sins. Who doesn’t want that?

Well, maybe you? Now after you’ve walked through the intellectual desert of a microservice approach to a problem that didn’t remotely warrant it (ie, almost all of them). Maybe now you’re ready to hear a different story. There’s a slot in your brain for a counterargument that just wasn’t there before.

So here’s the counterargument: Integrated systems are good. Integrated developers are good. Being able to wrap your mind around the whole application, and have developers who are able to make whole features, is good! The road to madness and despair lays in specialization and compartmentalization.

The galaxy brain takes it all in.

But of course, you cry, what if the system is too large to fit in my brain? Won’t it just swap and swap until I kernel failure? Yes, if you try to stick in a bloated beast of an application, sure.

So the work is to shrink the conceptual surface area of your application until it fits in a normal, but capable and competent, programmer’s brain. Using conceptual compression, sheer good code writing, a productive and succinct environment, using shortcuts and patterns. That’s the work.

But the payoff is glorious. Magnificent. SUBLIME. The magic of working on an integrated system together with integrated programmers is a line without limits, arbitrary boundaries, or sully gatekeepers.

Forget frontend or backend. The answer is all of it. At the same time. In the same mind.

This sounds impossible if you’ve cooked your noodle too long in the stew of modern astronautic abstractions. If you turn down the temperature, you’ll see that the web is actually much the same as it always was. Sure, a few expectations increased here, and a couple of breakthrough techniques appeared there, but fundamentally, it’s the same. What changed was us. And mostly not in ways for the better.

If your lived experience still haven’t hit the inevitable wall of defeat on the question of microservices, then be my guest, sit there with your folded arms and your smug pout. It’s ok. I get it. There’s not an open slot for this argument in your brain just yet. It’s ok. I’m patient! I’ll still be here in a couple of years when there’s room. And then I’ll send you a link to this article on twitter.

Peace. Love. Integration.