Under Pressure

There’s a sentiment in hiring I’ve run into recently. The idea goes that you want to see how someone works “under pressure” before you hire them. What does that look like? You build in a step with a task, add a tight deadline, and wait to see how the applicants cope.

In the worst cases, there is an expectation that giving any help to the applicant would skew the results. And besides, that quick turnaround helps keep the hiring timeline nice and short! That’s always a win. Or is it?

Let’s think about what this looks like to your new colleague. On their first few interactions with you, they get an arbitrary dreadline. The first taste of working with you is rancid and sour and artificial. Stress Max. All the angst, none of the calories. You’ve told them that applying for this job is the most important thing in their life. To drop everything and show you how they cope when times are tough. That asking for help is a weakness.

You’ve also rigged the result. You are far more likely to end up with someone who looks like the people who already passed through the fire. That pressure you are applying presses harder on people who are shorter on time. You might rationalize it to yourself with a “it’ll only take an hour, two tops”. And it is easy to feel that way when it’s your only responsibility. When you are finishing up your 3rd job, or working and caring for a relative, finding precious minutes to do this extra task well can feel impossible. You either accept that you’ll do second-rate work, or you cut into your sleep, or you let down the people relying on you for a chance at a better life. Suddenly, that pressure is costing you a chance to see the potential of your candidates. And for what? A weak simulacrum of the worst possible experience of working at your company.

That doesn’t mean that you shouldn’t look at the work. That doesn’t mean that you can’t have constraints. Looking at the work is one of the best tools we have to decide on who to work with. You can and should choose the scope of the work with care. Show the applicants what working with you looks like for real. Warts and all. If your business values thoughtful, careful work, give the applicant the time and support to do their best work. Treat them the way you treat the rest of your colleagues. Build up the trust battery, from the very first interaction. Make it clear how to get help, and what good work looks like.

Adding pressure to a system without a safety valve is a recipe for explosions.


Jason Fried and DHH talk more about dreadlines and the trust battery in their newest book: It Doesn’t Have To Be Crazy At Work. Check out the chapters “Hire the work, not the résumé”, “The trust battery” and “Dreadlines”. You can find out more at basecamp.com/books/calm

A question of skills

One of the first books I can remember reading was A Wizard of Earthsea. I was seven or eight, and it scared me to my core. That dark ocean was real and menacing in ways I couldn’t fully appreciate until later.

Beyond fear, one of the things that stuck with me from that book was the idea of true names. David Mitchell’s love letter to Earthsea paints the picture:

Knowledge of a thing’s true name brings mastery over the object, and as this applies to people as well, to tell someone your true name in Earthsea is an act of intimate trust.


I remember reading that tweet, and how violently I agreed with it. Hard/soft always felt jarring somehow. Ok, gone. I’m warming my hands on the smouldering embers of the dichotomy.

“So, what do we call them instead?”


Back in January, Seth Godin proposed vocational skills and real skills:

Let’s call them real skills, not soft.

Yes, they’re interpersonal skills. Leadership skills. The skills of charisma and diligence and contribution. But these modifiers, while accurate, somehow edge them away from the vocational skills, the skills that we actually hire for, the skills we measure a graduate degree on.

So let’s uncomfortably call them real skills instead.

Before we anoint a replacement, let’s take a moment. Why are we making that distinction? How does this benefit us? How does it help us to achieve our aims?

Almost everyone I’ve spoken with, and every post I’ve read, agrees that hard skills are easier to measure. That soft skills are more difficult to pin down, but equally important (I’d argue even more so). I can buy that. So what?

Dividing skills into types is an attempt to be more precise that costs us clarity instead of adding it. Our every instinct tells us that precision is valuable. Language is an evolving, imperfect attempt to describe the universe. When we reach for precision, we’re hoping to get closer to the true name of things.

There’s a trap here. When we spend time and wit seeking a more perfect description of the different types of skills, we’re working at the wrong level of abstraction. Precision only helps us if it changes how we act.


There doesn’t need to be a distinction. Skills are skills. We can teach them. You can learn them. There’s no meaningful difference in the steps you take to develop a ‘vocational’ skill or a ‘real’ skill, a ‘hard’ or a ‘soft’ skill. An authoritative taxonomy of skill types doesn’t change how you approach things.

What do we need to pick up a new skill? Well, some combination of the following:

  • Time
  • Desire
  • Access to knowledge
  • Practice
  • Observation
  • Making changes in response to what you observe
  • Support

Measuring success is the same whether you are learning HTML or practicing sincerity. You observe outcomes. You need to understand what you are trying to do before you do it, a core part of mastering any skill.

Making this change is pretty straightforward. When you are working on a job post, you already don’t mention hard or soft skills. You talk about the skills and experience you’d like an applicant to have. If you are working on a training plan for yourself or a team member, you can list the skills you want to focus on. Save yourself the mental overhead of working out if a skill is vocational or real. You won’t need it.

We can discard the distinction without guilt. Chipping away at gendered stereotypes is reason enough. Part of the evolution of language is recognising when words are no longer true, or shouldn’t be. We should seek a more comfortable level of abstraction, a truer name.

The names we choose matter.


With endless thanks to Ursula K. Le Guin, who influenced me more than I ever realized. A huge thank you to Erika Hall for prompting this in the first place. Thanks also to Mathew Cropper, Chase Clemons, Brad Stott, Elliott Hilare and Yechiel K for talking with me about this and helping me to see beyond my limits. 💚 to Chase Clemons, James Glazebrook & Wailin Wong for editing.

Interview or Interrogation?

Interviewing for a new job is so nerve-wracking. The adrenaline kicks in, and you are trying so hard to keep it under control. Trying to deliver the polished answers you prepared and rehearsed over and over. Hoping that you don’t slip up, or get tongue-tied. There’s the weight of an entire future sitting on your shoulders while you try to parse the questions.

Then there are the interviews where you get the feeling that the interviewer is trying to trip you up. I’ve had them in the past, but couldn’t be sure if I was imagining things. Did other people find interviews combative?

As we thought about how we would approaching hiring a new support programmer, we hit the books to find out.

Don’t expect to eat at lunch.

Though a company like Lending Club claims that lunch is a time for candidates to take a breather and relax, don’t. Your interviewers care about whether you are socially skilled and easy to be around…

…Lierman recommends that you pack a small water bottle and snack in your bag which you can nibble when you excuse yourself to go to the restroom.

How to Survive a Marathon Job Interview

There’s something fundamentally broken about a hiring process that inspires bathroom snacks as career advice. Articles like Nikki Brown’s dissection of “best-in-show” hiring processes weighed heavily. As a remote company, we can avoid the barbarism of the coffee shop interview, but how could we do better? What could we do to set up a candidate for success?

Flipping the script

So, we tried a little experiment. We set up interviews with our shortlisted candidates as usual. A few hours before the scheduled start time, I sent out the following email:

I’m looking forward to chatting with you later. Before we start, I thought I’d say hello and let you know that you’ll be chatting with Justin White and myself. I’ll invite you to the call at noon Chicago time. If you’d prefer to do audio only, that’s totally fine, same if you’d like to use video. Whatever makes it more comfortable for you.

We’ve got about an hour to get to know each other, and I was thinking it might be nice to start with any questions you have, then move on to ours. This is a collaborative chat — we want you to succeed, and it’s the start of working together. That might last for an hour or 5 years, or the rest of your career, but it starts here. Should be fun!

The big change was to flip the natural order of the interview, to start off with the candidate’s questions for us. They could get to know us, settle into the conversation and get comfortable before we asked ours. We wanted to set the stage, so that they could show us their best self. The best way to do that was to turn over the keys, and let them take the wheel.

The rest of the email reinforced that aim. From letting them know who they’d be chatting with, to giving them the time in their local timezone. Giving them control over how we would do the chat, to stressing that this is where their time at Basecamp starts. Acknowledging that this should be enjoyable, and setting them up to win.

We had some great conversations with all our shortlisted candidates. Relaxed, confident and in control, they gave a great account of themselves. Because we recognise that interviews are stressful, we took a more compassionate approach. That led us to a place where every one of our finalists gave their best shot, and some tremendous interviews. They were the most fun I’ve ever had on either side of the interviewing table. We made a great hire, and Rosa started her Basecamp career with our support, right from the very first minute of her interview. Now we get to keep that promise, every day.

Could you try flipping the script in your next set of interviews? What ideas do you have to build an even more collaborative approach? A little unscientific survey shows that we’ve got a way to go:

https://twitter.com/mackesque/status/873150905138413568

Can you help change those results? I’d love to hear your ideas.

Questioning a purchase

Today I was chatting with someone looking for opinions about project management software. It would have been easy to weigh in with a list of reasons why that person should try Basecamp.

But what if that isn’t the right way to help them?

Instead, I offered the following list of questions that I use when trying out something new. The answers to those questions might lead her to Basecamp, they might not.


What problem am I trying to solve? How does this help me get there?

This question is an old friend. A constant companion as I muddle my way through life. What am I trying to do? Do I know? Child questions spawn, dragging me closer to an imperfect answer that works for now. There is something powerful about the way asking a question reveals flaws in my understanding, or illuminates new avenues to explore. The beautiful thing is, behind each answer I find more questions.

Am I looking for something to help me do my work, or am I looking for something to change how I work?

How often do you really challenge the underlying assumptions about why you work the way you do? Picking up a new piece of software, or looking at a new process is a great time to pause and reflect. Are we doing this because it’s the right thing to do, or has it “always been that way”?

Does using this result in better work? How do I measure that?

This is one of the child questions that comes from asking what problem I want to solve. How am I going to know if making this choice is worthwhile?

If there is complexity, is there a payoff?

Not all complexity is anathema. Taking something complicated and turning it into something simple is a noble endeavour. Deciding not to do something is incredibly freeing. And yet, there is a place for complex processes, if they make life better at the end.

Does using this save me time?

Please!

This doesn’t do X. Does that matter? Could we do without?

When considering a move to something new, I often catch myself discounting a product because it doesn’t do something I’m used to. I’m trying to get better at ignoring that impulse, and being more open to changing how I work.


Are there any questions I’ve missed? Do you have a personal favourite you ask when looking at a new piece of software, or a new way of working? Let me know!


At Basecamp, we’ve got so many questions, and we’re having a blast trying to find the answers. We love questions so much, we built automated questions into the latest version of Basecamp. If you are looking for a calmer way to work, why not grab the questions above, and see if Basecamp 3 is the answer?

We’re looking for a support programmer

We’re looking for a support programmer to work with us as we build a safer, faster, better Basecamp. As well as working on Basecamp and our other apps, you’ll be an important part of our work on Basecamp, the company. You’ll be joining our existing support programmer (me!) and working as part of our Security, Infrastructure and Performance team in a fun and varied role that will help you to develop personally and professionally.


We want strong, diverse teams built from different backgrounds, experiences and identities. We’re ready for the ongoing work that goes into building an inclusive, supportive place for you to do the best work of your career. That starts with regularly working no more than 40 hours a week, and hopefully getting 8+ hours sleep a night. Our benefits are designed to support a sustainable, healthy relationship with your work.

Currently our team works from 32 different cities, spread across 6 countries. You can work from anywhere in the world, but your normal working day should have 4 hours or more overlap with Central Time (CST).


About you

Do you have questions?
Do you like finding answers?
Does helping people make your heart sing?
Can you approach problems calmly and compassionately?
Do you think clearly, and can you express yourself in English and in code?

About the job

Here are some examples of the kind of work you’ll be doing. You might not know how to do everything below, but you do know how to start looking and learning. Every single day, you’ll get to work across teams to support three major areas:

Making our customers happy.

  • You’ll be helping our customers to perform tasks they can’t do easily in Basecamp itself. We refer to these as concierge-style requests. They often involve writing small snippets of Ruby and working in a console
  • You’ll make it easier for companies to trust us by answering security and compliance questions
  • Every day you’ll be supporting our wonderful support team, to help them to ask better questions and find better answers for our customers
  • Developers who are working with our APIs sometimes need some help too, and you’ll be on hand to offer the right documentation, and suggestions on the best way to approach things

Working on our legacy

In the pursuit of answers, you’ll go delving into the codebase for all of our apps (including the very first Rails app!) to discover how things work. You’ll be comfortable looking at code, exceptions and logs, identifying problems and suggesting fixes.

Experience with Ruby, Rails and JavaScript would be very helpful, but if you have been using different languages and stacks, that’s fine too. Be sure to tell us all about it in your application.

As well as spelunking through our apps, you’ll work with people across Basecamp every day:

  • Working with our ops team to track down mail delivery issues, or networking problems or SSL certificate fun
  • Working with programmers to triage bugs, suggest fixes, and write code
  • Exploring issues with our Android or iOS apps, and working with our mobile teams
  • Support our QA team as they lead our feature retrospectives

Helping us find ways to be better

  • Triaging security reports & identifying fixes
  • Looking at reports of slowness in our apps and searching for the cause
  • Researching & planning improvements across teams, like ending support for RC4, or taking part in PrivacyShield certification
  • Looking at exceptions in our apps, and identifying fixes
  • Providing thoughtful commentary on product pitches, ideas and suggested fixes based on what you have seen
  • Investigating common cases, and coming up with ideas on how to reduce them

You’ll get support and trust every step of the way, and the freedom to make decisions to make things simpler, clearer, easier and more honest.


If this sounds like the kind of work you’d love to do, please apply. We’re especially interested in applications from folks in the early stages of their programming careers. If you know someone who would be perfect, tell them to apply! We’re accepting applications until February 3rd, 2017. Your cover letter is your chance to shine, so take it!

Time to toss resumes on the rejection pile

Ten years ago, I was unemployed. For fifteen months I tried and failed to find a job. I scoured the internet, the newspapers, asked friends, acquaintances, strangers for introductions or hints at where to find somewhere.

After a while, it was hard not to take the rejections personally, to value myself less with each “sorry, we’ve decided to go with someone else” or “we’re looking for someone with more experience”. To burn through savings, face the mounting debt and poverty and think that I deserved it.

To despair.

Well-meaning friends, advisors at the local Job Center and internet sites would give the same advice.

Focus on your resume.

Take the time to tweak your employment history here, edit your interests there, adjust your presentation to suit the company you are applying to. Tell a compelling story which makes it easy for the company to hire you for that job. It all makes sense that this is the way to go if you are going to be successful at landing an interview.

There’s an unchallenged assumption at the heart of this well-meant advice. That the resume is the best tool to market your skills, and no application is
complete without one. For many people, that assumption is actively harmful.

A resume is an effective delivery method for bias.

Take this study by Marianne Bertrand and Sendhil Mullainathan, which discovered that white-sounding names received 50% more callbacks. Or perhaps this study by Devah Pager, Bruce Western and Bart Bonikowski:

black applicants were half as likely as equally qualified whites to receive a callback or job offer. In fact, black and Latino applicants with clean backgrounds fared no better than white applicants just released from prison.

Terence Tse, Mark Esposito and Olaf Groth discovered that racial bias isn’t the only form of bias in play when assessing resumes.

CVs have led recruiters to focus too much on grades, university reputations, and prior work experience. The problem with these hiring criteria is that they’re biased toward applicants from more wealthy backgrounds. These families usually have better connections and networks, can provide better education opportunities, and can afford to pay reputable universities’ tuition fees. In addition, children who have grown up in the upper echelons of society are also much more used to the social norms that guide successful “acceptable” behavior

This bias works even if you know about it.

A resume is optimized to make it easy for hiring managers and recruiters to eliminate candidates. There’s a whole market of applicant tracking software designed to automate the process of easily discarding candidates which don’t fit certain criteria, based solely on their resume.

A resume is ineffective at finding the best employees.

There’s an excellent essay by Reginald Braythwayt, I don’t hire unlucky people, which includes this fable:

Bertram smiled. He grabbed a pile of resumés from his desk, then started dealing the resumes out, first one back onto his desk, second into the recycle bin, third onto his desk, fourth into the recycle bin. When he was finished, he had thrown half of the resumes away. “It’s simple.” Bertram told Ernestine. “Just don’t hire anybody who’s unlucky.”

I’d hope that businesses take the search for talent more seriously than that. And yet, we look at a resume as proof that past success leads inevitably to future success. If you want to find the best people, you have to dig deeper than that. What someone has done is not as interesting as what they are capable of doing. Hire for the person they’ll become:

A lot of future perfect people are stuck in current mediocre positions. They just haven’t had the chance to do their best work.

So what do we do instead?

I’m not suggesting that if you are looking for a job, you should abandon your resume. Work the system, send it in. Get paid. The onus for this change lies with employers. If we’re serious about finding the best candidates, whoever they are, then it’s time to reject resumes. Not just the unlucky half, but all of them.

What would happen if the next time you are hiring, you ask for no resumes?

Provide some simple instructions as part of your job post. Ask for a cover letter, not a resume. Describe what you are looking for in the cover letter, and what you don’t want to see. This almost certainly means that you’ll need to do more interviews. Expect that. Spend that time having good conversations about the skills and qualities you are looking for, and give your applicants the chance to shine. Consider structured interviews and create a rubric for scoring them, to further reduce the impact of bias on your hiring.

Give it a try. Maybe you’ll find a way to a more diverse, talented workplace.

Building on kindness

Illustration by Nate Otto. DIY ✌🏽skills✌🏽 author’s own.

Last week, everyone who works at Basecamp was asked if they had any home improvement tips. In the spirit of sharing the fruits of hard-earned experience, I confessed to my colleagues about the time I tried to hammer in a screw.

Now, this is not a parable about the hacker ethos. I was not a hero, scrappily doing whatever it takes to get the job done against the odds. I was a fool, and I ruined that desk. Use the right tools if you have them.


There’s a tool I reach for more than any other. It’s hard to use, exhausting even. It’s never the fastest option. It takes longer, costs more, and people don’t always appreciate the extra effort. You might be thinking that with my track record, I clearly can’t be trusted to pick the instruments of work. Bear with me. I’ll try to explain.


I’m lucky enough to spend my life in the pursuit of happiness — mostly the happiness of others. My craft is devoted to finding ways to make life better for the people we support. To find answers to questions. To seek out solutions to problems. To anticipate need, and fulfill it before our users even realise that they have that need.

When we talk about the skills needed to be good at support, we talk a lot about empathy and understanding. The world is in desperate need of more of both, but empathy and understanding on their own aren’t enough. We need my favourite tool, with all of its infuriating complexity. We need kindness.


I’m not talking about random acts of kindness or paying it forward. I’m talking about a conscious decision to view the world through a lens of consideration for other people, and to act on it. People remember how you make them feel. What would it take to make the person you are talking with feel that you care about them? How can you demonstrate that you value their time, that you want them to do great things? How can you help them be amazing?

Here’s the rub. I don’t know. I’ve got a bunch of guesses, and a willingness to try, even if it costs me. I’m hammering away, and hoping I’m hitting nails. So here’s a few things that I’ve learnt about kindness.

  • Optimism is the well that kindness draws from. It’s really hard to be kind when you aren’t positive.
  • Like any well, don’t draw too deeply. Life can be brutal, and giving too much of yourself is a mistake. Be kind to yourself in times of drought, and build from there.
  • Positivity can be exhausting, but it gets easier the more you practice it.
  • Some people don’t deserve your kindness, but giving it freely anyway is worthwhile.
  • On the other hand, being kind doesn’t always mean being nice. Being kind doesn’t always mean being polite.

Sometimes, the kindest thing you can do for a person is to tell them to go fuck themselves.

Those times are likely to be rare. Give it five minutes.

Let’s build.

So, how do we go about bringing a spirit of compassion into our work? I’m going to spend the rest of my life trying to figure that out, starting with these examples from some very smart people.

kindness.perform!

There are plenty of opportunities to practice kindness while using code to solve problems, but here’s one of the easiest to do immediately. When you write your next pull request, make sure to explain the why, as well as the how of your changes. Duretti Hirpa explains who benefits from this generosity beautifully:

Future me encompasses a lot of people: future engineers on my team, new and veteran alike, trying to make sense of decisions made, or engineers trying to diagnose problems, who weren’t involved in the original changes, but are involved now because of something past me missed. So, I provide context, as best I can, to the once and future me.

On Purposeful Repetition — Duretti Hirpa

Designing with compassion

Three years ago, Mike Monteiro gave a talk at Webstock ’13 called “How Designers Destroyed the World”. It struck me, and stuck with me. Watch it. It will probably make you uncomfortable. Watch it anyway.

We have to be confident enough in what we are doing to be honest about what we are asking for, and why. We must leave our own comfort zone, rather than ask our users to leave theirs.

That quote comes from Design for Real Life by Eric A. Meyer and Sara Wachter-Boettcher. If you are involved in building a product or service, you should read this book. You will come away with techniques to bring compassion into your designs, and we’ll all come away with better products.

My favourite feature of Basecamp 3 is Work Can Wait. We live in a world where it has never been easier to work all the time, to expect immediate responses. That has brought us tantalising possibilities, and blurred the lines between work and play. Work Can Wait came from a desire to bring those lines back into sharper focus, because we think 40-hours work a week is plenty. Giving you the power to get notifications only when you are working sets the right expectations. Making a 40-hour week — plus some wriggle room for early starts or late finishes — the default reinforces them. As an example of designing with compassion, it’s a small start. We can, and must, do more.

Approaching work with calmness, consideration and generosity changed my life. I’m going to make mistakes, and try to hammer screws, but I’ll try to learn from it. I hope you’ll join me in this great adventure.

Go. Be kind. 💚


Thanks to natalie, Chase Clemons and Wailin Wong for talking this one through with me.