Some advice from Jeff Bezos

A number of years ago, Jeff Bezos stopped by our office and spent about 90 minutes with us talking product strategy. Before he left, he spent about 45 minutes taking general Q&A from everyone at the office.

During one of his answers, he shared an enlightened observation about people who are “right a lot”.

He said people who were right a lot of the time were people who often changed their minds. He doesn’t think consistency of thought is a particularly positive trait. It’s perfectly healthy — encouraged, even — to have an idea tomorrow that contradicted your idea today.

He’s observed that the smartest people are constantly revising their understanding, reconsidering a problem they thought they’d already solved. They’re open to new points of view, new information, new ideas, contradictions, and challenges to their own way of thinking.

This doesn’t mean you shouldn’t have a well formed point of view, but it means you should consider your point of view as temporary.

What trait signified someone who was wrong a lot of the time? Someone obsessed with details that only support one point of view. If someone can’t climb out of the details, and see the bigger picture from multiple angles, they’re often wrong most of the time.

Great advice.


Some advice from Jeff Bezos was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.

Real Work vs. Imaginary Work

Since we launched Hill Charts in Basecamp we’ve been fielding many interesting questions. One common question is: how do we catch more problems in the uphill phase so they don’t surprise us later?

What happens is, people think a piece of work is downhill, and then all of a sudden a problem comes out of nowhere. Especially when it comes to programming issues. “Why didn’t we catch this earlier?”

The reason often traces back to the uphill phase. An engineer looked at some work and imagined the solution in their head. “Yeah I don’t think that’ll be too hard.” They saw in their head how to do it, so they positioned the work at the top of the hill.

What happened next? After they got their hands dirty and started building, the reality turned out to be more complicated.

The problem is the uphill work was imaginary. Thinking about how you’re going to do something is not the same as rolling up your sleeves and trying.

The solution is to start at the bottom. If all of you’ve done is thought about the solution, then mark your status at the bottom left of the hill to show you haven’t built anything yet.

Start at the bottom when the solution is still imaginary

Now to move uphill, write some code to prove out the idea. Pick out the most essential steps or moving parts and write enough to validate the approach. Some teams call this “spiking” or “stubbing out” the work.

Doing real work to move uphill

You’ll still run into the unknown. But the difference is now you and the rest of the team expect that to happen because you’re still in the uphill phase. In fact all of your development work on this side of the hill is about spiking the unknowns and finding these trouble spots.

Catching the problem on the uphill side

You can’t bet on work that isn’t over the hill. So nobody will be surprised if a problem comes up on the left side. This is a healthy time to get stuck.

There could be a variety of solutions. Maybe you need to put heads together with your peers. Or get advice from someone senior. Or consider a different package or library to do what you want. Whatever the solution, everyone can see the problem as a step toward figuring out what’s going to work — what’s going to make it over the hill.

Doing work to get over the hill gives you more certainty

Having spiked out the most important parts of the problem, you can be confident that what’s left really is just a matter of execution. Sure there will be little surprises, but you’re less likely to run into something that blows the budget or breaks important assumptions.

The key point here is: imaginary work doesn’t count. Get to running code early. Or a rough interface. Or an outline of the copy. Whatever it is, the way to get uphill is to roll up your sleeves. Seek out the things that might go wrong and show evidence that the approach will cover them all. Then when you get to the top of the hill, your team can trust that the work is really going to ship as planned.


Real Work vs. Imaginary Work was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.

Leaders, stop being so nice all the time.

“Being nice” can be a crutch to avoid hard choices and uncomfortable conversations. Don’t fall into this trap.

Leaders, stop being so nice all the time.

I don’t mean to sound like an asshole. But when it comes to leadership, it’s true: Prioritizing “being nice” keeps us from being good leaders.

Now I’m not advocating for us to be mean. Disrespectful or dismissive leaders help no one. Rather, I’m calling for us as leaders to loosen our grip on “being nice.” To stop wanting our team to like us all the time. To let go of the expectation that every single interaction with our team should feel good.

Truth is, our team isn’t going to like us all the time. Our team isn’t going to feel good all the time. And trying to be nice to everyone all the time isn’t going to change that. Nor is it actually helpful for your team.

When we’re preoccupied with seeming popular instead of fair, when we optimize for pleasant conversations instead of honest ones — we hurt our teams.

I was reminded of this most recently while I was reading The Watercooler, our online community with almost 1,000 leaders. One manager revealed he was facing this exact dilemma. He was seen as “The Nice Guy” in his company, always complementary, never critical. As a result, he was struggling how to start giving his team difficult feedback — and his team was floundering.

He’s not the only one.

Have you ever found yourself in one of these situations?

  • You avoided giving tough feedback to a coworker… and now the person has made even bigger mistakes than you previously imagined.
  • You didn’t tell someone that you disagreed with them… and now you have to figure out how to course-correct without blindsiding the person.
  • You postponed firing someone… and now have to do damage control for the low morale they infused throughout the team.
  • You said something was “great!” even though it actually wasn’t… and now you have to fix the level of quality for what was produced.

Many of us focus on “being nice” as a leader more than we should. And we pay a price for it.

Hiten Shah, founder of Kissmetrics and Crazy Egg, emphasized this point to me, in a recent interview. He warned that when you’re concerned with being nice all the time, “there’s a level of toxic culture that develops that’s hard to see, especially on a remote team.”

Prioritizing “nice” as a leader is an easy trap to fall into. Being nice fits into our desire for belonging and companionship as humans. We’re social creatures. We want to be liked. Inherently, there is nothing wrong with that.

But “being nice” becomes problematic when it becomes your rudder as a leader. It leads you astray. You lose sight of your purpose as a leader: To help your team accomplish a specific mission. Your barometer for success as a leader morphs from “Are we accomplishing our mission?” into “What does the team thinks of me?

Over time, “being nice” becomes your crutch. It’s a convenient rationalization to avoid hard decisions, uncomfortable conversations, and controversial actions. It’s easier to “be nice” than it is to have tell someone to their face that they’re rubbing a client or colleague the wrong way.

Ultimately, being nice as a leader is selfish. It doesn’t serve the team. It serves your ego. The team is looking to you to help them achieve a goal. And instead, you’re looking to have your decisions, actions, and yourself perceived as positive by them.

A leader is the only person’s whose sole job is help a team achieve the outcome they want to achieve. When you care about “being nice,” you’re essentially saying, “The needs of my team as a whole don’t matter as much as their perception of me as an individual.”

Instead of seeking to be nice, we should seek to be honest, rigorous, and consistent.

Or even better, we can seek to be nice and honest, nice and rigorous, nice and consistent. One of my favorite books, Crucial Conversations, discusses how being nice and being honest are not mutually exclusive. You can be both. The best leaders embrace this duality.

Let’s just stop being so damn focused on being only nice.

P.S.: If you enjoyed this piece, please feel free to share + give it 👏 so others can find it too. Thanks 😊 (And you can always say hi at @clairejlew.)


Leaders, stop being so nice all the time. was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.

Teaching iteration

I’ve written about the class I’d like to teach, but what I’ve been thinking about lately is the class I’d like to attend. Not necessarily now, but when I was growing up. In the 6th grade, let’s say.

I don’t know why people ask me this, but I’m often polled for my opinion on the American education system. What’s my take? What would I do to fix it?

I don’t know, really. “It” covers too much ground to be addressed accurately. Education is delivered at every scale, from an individual reading a book, to a 1:1 tutor, to a small home/classroom setting, to a larger university auditorium-sized class, to online classes that can be theoretically taken by the entire planet at once. From one to 7 billion.

You can’t fix anything that’s so big and so varied. You can, however, fix small parts of things. And hopefully, as the small, fixed parts add up, you have a chance at chipping away at a big problem.

So here’s my one small idea: I’d begin to teach iteration. Iteration as a subject, equivalient to math, science, history, language, art, music, etc. How do you make something better over time? How do you return to something that you’ve done and see it with fresh eyes? How do you apply new perspective to an old problem? Where do you find that new perspective? What trails do you follow and which do you ignore? How do you smash the familiar and reassemble something new from the same pieces?

Once you’re done with school, and cast out into the world, your job is likely to involve iteration. No matter what you’re doing, you’re probably going to have to do something over. And often times again and again. You rarely simply deliver something and move on. You’re asked to refactor, to build on it, to “make it better”.

Making anything better is iteration. When you put something out there, it’ll often land right back in your lap. Sometimes that feedback boomerangs back directly, other times you have to infer the problems by disciphering other people’s behavior when they interact with the thing you gave them. This customer struggled with this, this manufacturing tolerance didn’t line up with that, this printing process looked better on the screen than it did on paper. Or after a certain amount of time passes while working on something, you reflect on what you’ve done and don’t like the reflection.

Either way, someone’s probably going to ask you to take the state of your art, and make it the state of the art.

Now that you’ve got it back, what do you do with it? This is something you have to learn how to deal with. But in school — save for writing a few drafts before handing in the final version — you don’t get to iterate much. You move on from assignment to assignment, rarely getting a chance to revisit your work earlier in the semester. I think that’s a missed opportunity.

So, perhaps for a final assignment (no matter the subject), students should be able to choose something they did earlier in the year and get a chance to improve on it. Make version 2. I think working on four things, and getting a chance to redo one of them would be more valuable than working on five separate things. It would be a better education.

Or another take would be a single assignment for the entire semester. Every two weeks you hand in a new version of it. In time you may slam into diminishing returns, but that’s all part of it too. That would be a better education.

Or maybe you work on something and hand it in. Then the teacher shuffles the deck, so to speak, and hands you back someone else’s assignment. Now you have two weeks to improve on that. And that cycle — improving on someone else’s work — continues for the whole semester. That would closely mirror what work on the outside is really like. That would be a better education.

I don’t know, something like that.

So there, I guess that’s my initial idea to improve the educational system. Teach problem solving through iteration. Bounce things back to people for a second or third try. And then a fourth and a fifth. And so on. Require them to bring new perspectives. Demonstrate how time, space, and chance are on your side — they give you the opportunity to wander around with an idea and take it in new directions. Iteration is evolution. Hopefully what’s next is better than what came before it.


Teaching iteration was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.

New in Basecamp: Recurring Events

Now you can add [daily, weekly, monthly, yearly] repeating events to the Basecamp schedule. Here’s how it works:

When you add an event in Basecamp 3…

…you’ll see a new option to repeat the event…

…the options include every day, every week day, once a week, once a month, and once a year…

…you can choose to repeat the event forever, or until a certain date…

…the repeat frequency is shown on the event page as well…

This feature has been a long time coming. Thanks to everyone who sent in a request, to Merissa on the support team for championing the push to make this happen, and to Jeff, Conor, Pratik, and everyone else who pitched in to help make it all work. The new feature is live for all Basecamp 3 customers on all platforms (Web, Mac Desktop, Windows Desktop, iOS iPhone + iPad, and Android). We hope you find it useful.


New in Basecamp: Recurring Events was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.

Managers who brag about their stress and exhaustion don’t need our applauds

Stock photography of fake tired people is also kinda exhausting!

Managers used to be the object of envy for their leisurely workday. Maybe it included showing up half an hour later than the norm. Maybe it was that mid-day session of golf. Maybe it was skipping out early on a Friday.

In an age of back-breaking manual labor, it’s understandable how such disparity was cause for contempt. But for much of the economy, those days are over.

And yet it seems that far too many managers have internalized a deep sense of guilt from that era, so they desperately try to convince themselves and others just how hard they’re working! How worthy they are of their perched position on the hierarchy. How important their constant gaze and vigilant action is for both their company and the economy as a whole.

Thus is the sign of insecurity. When you deep down know that your 24/7 efforts just aren’t as important — or even desired! — as you’d like to believe, the quickest way to quell those nagging thoughts is to doubling down on the bravado. You don’t think I work? Oh, let me show you!!

Overcompensating like that may or may not be a conscious process. It’s probably easier when it’s not, but that doesn’t mean it’s easy in any psychological sense of the word. It’s hard work to dance with dissonance, cognitive or otherwise.

But to keep dancing like this, you need someone to provide the music, and the media has been all too willing for all too long. Fawning article after adoring hagiography. Look at this marvel of a monster manager! Up before anyone, to bed later than all! No vacation for 20 years! Bathroom breaks strategically picked to squeeze out 120-hour weeks! You should all be in awe of these super humans!

It’s time for the music to come to a halt. Stop lionizing toxic work habits as inspiration for new entrepreneurs and managers. Masochistic managers can continue their self-immolation for The Mission and The Company, but the rest of us and the media do not need to bang the tambourine while they do it. Because that shit already trickles down enough as it is. We don’t need to help it.

Instead we should look with pity on such a narrow existence. And frequently with the appropriate level of ridicule and scorn when the performative aspects of exhaustion get too over the top.

Let’s return to a time where being a harried mess of a human wasn’t the high managerial calling it is today. But let’s spread that luxury wider. Instead of turning everyone into the overworked peon of the early 20th century, we should be striving for everyone to be able to take off early on Friday for golf. Or enjoy that long lunch. Or pick when they come into the office.

Jason and I have have sought to become calm managers in a calm company for the better part of twenty years. It was our continued frustration with the endless exhaustion bravado that lead us to pen our latest book: It Doesn’t Have To Be Crazy At Work. It’s coming out October 2nd in the US.


Managers who brag about their stress and exhaustion don’t need our applauds was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nintendo Switch Does Multiple Accounts Right

Multiple Accounts in a product is a difficult to design for. It’s not a typical thing, though. Most have just one Google, Apple, Instagram account. However, some might want to share an iPad or HomePod with family. Since those don’t support multiple accounts, the owner’s profile ends up overrun by someone else’s preferences. It’s an edge case that’s difficult to design.

Basecamp 3, the product for which I design the Android app for, does support multiple accounts. You can flip between your Personal Basecamp, Work Basecamp, and other Basecamps you’re part of. The design keeps each Basecamp’s data and preferences separate.

A few months ago our family got a Nintendo Switch. I didn’t think too much about how easy it is to share. The system is so intuitive that you actually don’t have to think about it too much. It wasn’t until today that I really looked at how simple and elegant the multiple account setup is on the Switch.

The Switch Home Screen displays the game library

Nintendo has the benefit of just dealing with one thing: Games. But each game has its own preferences, save data, difficulty settings, etc. I might be further along than my 9-year-old. My 14-year-old might be further along than me, etc.

Our Switch has 3 accounts

The coolest thing is you can see what game was last played and who has been playing it. Currently it’s my 9-year-old.

Currently playing

When you select “Change User” you get this panel. This panel also displays if you select a game that isn’t currently being played.

Each account can have its own instance of the game

If you want to add a new account you can just tap the “+” button.

Easy to add another account

When I select my account…

I’ll change the instance of the game to my account

The Switch shows that my instance of the game.

You can tap the Profile pictures in the top left corner of the Home Screen to get to the Account profiles.

View my account

Each Account has stats and settings that are separate from one another.

My profile

The best detail about this system that Nintendo designed is that every Account is “logged in” when the device turns on. The Games, however, can be switched between Accounts so that each player can start again where they’ve left off.

It’s a novel approach that doesn’t get into the business of switching the entire Home Screen for each Account. Nintendo’s Multiple Account system gets out of the way so you can all enjoy sharing the Switch and playing games as a family. Pretty cool.

Any other devices or apps that handle multiple accounts particularly well? Let me know in the comments below.


Nintendo Switch Does Multiple Accounts Right was originally published in Signal v. Noise on Medium, where people are continuing the conversation by highlighting and responding to this story.