Working remotely builds organizational resiliency

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.

Live Q&A on remote working, working from home, and running a business remotely

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.

A live tour of how Basecamp uses Basecamp to run Basecamp

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.

Remote Working: The home office desks of Basecamp

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”

How we acquired HEY.com

Back on June 9, 2018, I cold emailed help@hey.com:

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.

Keep digging

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.

The books I read in 2019

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”

Mailing list software should stop spying on subscribers

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.

Integrated systems for integrated programmers

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.

Testimony before the House Antitrust Subcommittee

My name is David Heinemeier Hansson, and I’m the CTO and co-founder of Basecamp, a small internet company from Chicago that sells project-management and team-collaboration software.

When we launched our main service back in 2004, the internet provided a largely free, fair, and open marketplace. We could reach customers and provide them with our software without having to ask any technology company for permission or pay them for the privilege.

Today, this is practically no longer true. The internet has been colonized by a handful of big tech companies that wield their monopoly power without restraint. This power allow them to bully, extort, or, should they please, even destroy our business – unless we accept their often onerous, exploitive, and ever-changing terms and conditions.

Keep reading “Testimony before the House Antitrust Subcommittee”