Twelve Weeks @ Basecamp: A Summer Tale

Prelude

I found out about Basecamp’s internship program during the winter break completely on accident. Burned out from the fall semester and unmotivated to get any work done, I gave “data science internship” a cursory Google search and happened to find Basecamp had just posted about looking for summer interns.

After reading through the description and learning about Basecamp’s kill on the cover letter mantra, I knew this application wouldn’t be like others. I meticulously combed over my resume and cover letter to make sure I was making my reviewers’ job as easy as possible. It isn’t just about checking off each requested application component: your application materials should speak to your personality, experiences, and really show the reviewer that you can deliver. Basecamp’s application reviewers had to put in tons of work, and to quote Ann:

Tell us your qualifications
Demonstrate why you’re qualified. Sounds like a no brainer, right? People applied for programming internships without showing us any projects they worked on, or even describing their experience in any depth. We’re not looking for fully formed apps — these are interns after all. Projects for classes are great. Bootcamp projects are great. Simple design portfolios are all we’re looking for.

Lesson learned: don’t give application reviewers even the slightest room to reject you — their review of your materials should be as straight-forward and applicable as it should be, and no more.

(A short aside: I decided to have some fun with my cover letter by including my attempt at digitally sketching Basecamp 3’s Happy Camper mascot. Nobody has said anything to me about it, but I’m convinced this gave me a competitive edge.)

Let’s be real: this is how you kill on a cover letter.

True to his word, Noah reached out to me on March 1st asking me to set up a quick phone interview with someone on the Basecamp team. I was thrilled, excited to reignite my skills, and mostly worried.

My first call was with Eron, one of Basecamp’s Ops extraordinaire (Fun fact: Eron once informed me that I tried querying our internal timeseries database with a start time of 70 seconds after January 1, 1970, which broke a thing or two. We don’t talk about that.). We had a cool discussion around the problems Basecamp had faced in the past with respect to load balancing, and the architectural challenges therein. Whereas Eron had worked on an in-house system for load balancing in the event of a Distributed Denial of Service (DDoS), I hadn’t ever really considered the load balancing problem. The conversation was really cool, though, because the problem domain presented interesting avenues for solutions and got us talking. No useless technical screen asking me to implement a Hash-map, no quiz on the internals of Python’s GIL. Lesson learned: few companies know how to properly evaluate prospective interns — Basecamp is one of them.

Around two weeks later, Noah got in touch asking for another phone interview. Okay, I thought, now we’re in the big leagues.

It was interview time. For the past two weeks I had been preparing myself for anything Noah might throw at me that was fair game — SQL queries, Postgres internals, Python trivia, etc. Imagine my surprise when we talked about my personal projects, my interests, having to context switch between MySQL and Postgres queries, and how I’d be able to contribute to Basecamp’s data infrastructure. I remember ending the call thinking I was a bit too casual — after all, not one line of code was written during a startup’s interview process? I must have been funneled into the “call, but don’t bother asking to code” subset. I sent Noah a thank-you email and figured that was the end of that — after all, there was only room for one data science intern.

One.

Three weeks later, I was at the library studying for midterms. Ding. I checked my phone. “Join us at Basecamp this summer!” Lesson learned: don’t let your dreams be dreams. (Actual lesson learned: the logo worked!)

Present

So what did I actually do at Basecamp? With Noah’s frequent guidance I built Thermometer, which is our embarrassingly-parallel aberration detection system designed to autonomously report any aberrations across our 10,000+ internal metrics in real-time. Thermometer was both an engineering and data science challenge — I constantly thought about the trade-offs between performance and statistical rigor, and with Noah’s help quickly settled a great equilibrium.

Alongside Thermometer I also developed and internally released Thermos, an R package designed to keep Thermometer’s logic straightforward and abstract away the nitty-gritty bits of anomaly detection. I learned a ton about package development and came to truly dedicate my allegiance to the Hadley-verse.

Towards the end of my time here, Noah and I have been pairing up and walking through a few different A/B tests. Each time I get to pair up with Noah on a task, it’s really humbling to see how much I can improve as a data scientist. Things that would take me at least an hour or two to recognize, diagnose, and implement is a casual 1-line fix for him. Lesson learned (in the best way possible): you don’t know anything — yet.

Retrospective

In Noah’s retrospective on hiring Basecamp’s summer intern class, he mentions three core reasons Basecamp was offering internships:

Give back and have an impact on the community
Challenge ourselves to grow
Improve Basecamp (the product and company)

I like to think that as a data science intern, I was able to consistently experience the intent behind all three everyday.

Problem-solving, meet the real world

When building Thermometer there were times where I lost sight of what to do next — there was so much! On top of having to deal with real world edge cases and meet certain features, I had never worked on something this conceptually large before. Not to mention I owned 100% of all the commits to Thermometer and Thermos — I should be Noah’s go-to for questions on Thermometer, not the other way around. Time and time again, however, I would ping Noah about a function I had written and ask about code quality, logic integrity, and more.

This isn’t to say I was struggling for air — I also got to propose solutions, discuss trade-offs of pursuing potential solutions, defend certain design decisions, and really feel like a full-time member of the data team. Treating interns as employees was without a doubt the norm at Basecamp, and it reinforces the people-first culture of betterment and transparency at all levels.

The Boy Scout Rule

Always leave the campground cleaner than you found it.

Working on Thermometer and Thermos gave me the opportunity to impact a real-world system at scale. Sharing my achievements with the company was a total confidence-booster, and as a builder it’s awesome when people use something you’ve made. I’ve left Basecamp in better shape to handle data problems in the future than how it was before — and in many ways that has made all the difference.

Parting Words

Basecamp surrounds its interns with so many opportunities to grow, collaborate, learn, and contribute. I’ve been fortunate to gain a crazy amount of both technical and domain knowledge, and it’s in large part thanks to the two-fold effort from the culture’s emphasis on communication and transparency and Noah’s exceptional skills as a data scientist, multi-tasker, and mentor.

Each day presented another challenge, and I got to learn from and face each one with a wide smile. There’s no better feeling than solving a problem you’ve been stuck on for days and knowing that your work is going to be used to support an entire organization, and I’ve grown to appreciate those hair-pulling moments of frustration as learning experiences.

Lesson learned: Basecamp isn’t about implementing bleeding-edge machine learning algorithms or dominating the market— it’s about people helping people. That’s it.


If you liked this post, please hit the ❤️ button below. Thank you!

Feel free to send me your thoughts, questions, and prayers on Twitter.

The one product feature that tripled our sales last month

Here’s how the tiniest Know Your Company feature that took 20 minutes to code led to the biggest impact on our business…

Even the smallest lever can have a big impact.

A few months ago, we moved Know Your Company to self-signup. This means that when people come to our site, they can sign up for the product themselves, give it a spin for free for two weeks, and decide whether or not they want to purchase it. (Prior to this move to self-signup, we sold our product manually, via in-person demos that I would do myself.)

After we launched self-signup, the first month was a little slow. We typically see 4–6 sales a month. But in May, we only saw three sales come through self-signup.

Hmm. Three sales wasn’t abysmal, but it wasn’t promising either. If Matt (our other employee at Know Your Company) and I wanted self-signup to work and help more people benefit from Know Your Company, we needed to find a way to get more than three sales from self-signup in a month. Like a lot of folks who run software products that offer a free trial period, we needed to figure out: How do we improve our trial to convert more signups into sales?

To answer this question, we set out to talk to the people who we knew would know: our potential customers.

Going to the source

We emailed a handful of people who’d signed-up for Know Your Company but had not bought the product. We asked if they’d like to jump on the phone for 10 minutes to help us figure out what we could improve. If you were curious, here’s an example of an email we actually sent:

Hey Josh,

Happy Wednesday!

My name’s Matt, and I’m a programmer with Know Your Company. Just wanted to say hello and say thanks for checking us out!

I’ve got a small favor to ask…

I’m doing some research to better understand why people try Know Your Company. Would you be willing to chat by phone for 10 minutes?

If so, just let me know when (and a good number to reach you)! Thanks Josh — this would be a big help as we improve our service 🙂

Best,
Matt

We sent this email to about twenty “good fits” — CEOs who’d signed up for the product and had 25–75 employees (this is who the product works the best for). We ended up getting on the phone with about six of them.

From these conversations, we found that the #1 reason why these CEOs didn’t buy Know Your Company after trying it out was because of the participation rate. The number of their employees’ who responded to questions was lower than what they expected.

These CEOs were typically seeing ~25% response rates with Know Your Company. On the flip side, companies who had purchased Know Your Company had seen at least 50% response rates during their trial. Interesting.

We walked away with a huge insight from those customer conversations: For CEOs, participation from their employees was the indicator of success for the trial. Seeing their employees actively participate with Know Your Company is when they have the “ah ha moment” that this is something that adds value to their company. It’s the barometer they use to see if Know Your Company is working for them.

And I get it. Know Your Company is about helping you to get to know your employees better. And if only three out of your twelve employees you’ve added to Know Your Company are answering, the quality of the insights you receive are going to feel underwhelming.

So Matt and I started wracking our brains… How do we help our CEOs achieve what they see as a successful outcome with the trial? How do we help them see the participation rate that they’re expecting?

Direct, small, and easy

We decided to approach it from the most direct way possible: What if employees simply got a friendly, nonintrusive email reminder asking them to respond to a Know Your Company question, if they hadn’t yet?

I could imagine how easy it was for an employee to forget to respond to the Know Your Company question or even outright ignore it — especially if they weren’t 100% convinced yet that it was a genuine effort on the part of their CEO.

We chose to design the email reminder around the Company Question — it’s a rotating question we ask every Wednesday about something specific in the company (for example: “Do you think the company is the right size?”). The Wednesday Company Question is the one our CEOs often tell us that they receive the most insights from and feel the greatest impact. That being the case, our thinking was… if a CEO could see a significant response rate to the Company Question during their trial, perhaps she or he would want to buy the product.

Here’s what we came up with. For anyone who hasn’t yet answered the Company Question she or he receives an email that looks like this:


In this example, the email is coming from Victor, the CEO in the company (all Know Your Company questions come from the CEO), addressing the employee, Jared.

You’ll notice a few things about this email. It’s friendly, and natural-sounding. It was important to us that this email didn’t bug someone or didn’t feel nagging.

In fact, we were so worried about bugging people, that if someone also forgot to answer the Company Question during the second week of the trial, we created an alternate email with different wording to send to them so it wouldn’t feel too stale or automated.

The email reminder also points out the importance of answering the Know Your Company question (note where it reads: “it’d really help us see how Know Your Company could be a useful tool for the company”). We wanted to make sure this was clear to employees — that answering this Know Your Company question would help their CEO understand if the tool was a good fit for the company or not.

What were the results?

Since launching this feature on June 7th, the average company question response rate amongst trial signups has gone up to 41% (it was previously 25%).

We saw our sales for last month triple — we did nine sales in June. If you recall, we’d only done three in May. This is the highest number of sales in a month we’ve done this year so far, and it matches the highest number of sales we’ve done in a month ever.

Six of those nine sales came after the launch of this feature, with two of those companies seeing their response rates improved by 3X and 4X than what they had previously been before.

One caveat is that we had a high increase in the number of inbound leads: We saw more than 3,000 visitors come to the Know Your Company website week that this Fast Company article was published, and that traffic bump continued throughout June. So we did have a significantly larger pool of leads coming in June.

Yet in spite of this, there’s a distinct difference in our conversion rate before and after we launched this feature. Our conversation rate from signup to sale was 15% for June. In May, it was 5%.

As a whole, I think it’s fair to attribute the dramatic boost in sales last month to this one, tiny little email that barely took any time to code.

A few lessons learned

It blows my mind that something so small, and required such little time and technical complexity, was able to have such a profound impact on our business.

It was an important reminder for me to “play detective” in our business. To look in the nooks and crannies of our business for insights and learnings that can help our customers get more of the outcomes that they want to see.

Specifically, it reminded me to…

1) Ask yourself: What barometer do potential customers use to judge whether or not this product is going to work for them? What’s the equivalent of a “high participation rate” in your business?

2) If you don’t know the answer to the question in #1, go talk to your potential customers to answer this question. It’s easy to forget that your customers and potential customers truly do have all the answers. They will tell you what they were doing before they used your product, when they decided to switch and purchase your product, and the forces that influenced them along the way. All you have to do is ask.

3) Don’t be afraid to try something direct, small, and easy. Matt and I looked for the most direct way we could impact the outcome that our CEOs are looking to have. And we didn’t dismiss an idea it because it wasn’t technically advanced enough or “a big enough idea.” It’s amazing how something as small as one email can make a difference in your business.

For you, I hope sharing this reminds you as much as it did me to be on the look out for truffles like this. Even the smallest lever can have a big impact.


Big news! We’re now Know Your Team. Check out our new product that helps managers become better leaders, and get the full story behind our change.


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

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.

Infrastructure worth investing in

I analyze data for a living. I occasionally do some other things for Basecamp — help with marketing, pitch in on support, do some “business” things — but at the end of the day, I analyze data. Some of the data is about feature usage, some about application performance or speed, some about our great support team, some about financial matters, and some of it defies categorization; regardless of the type of data, my job is to identify business problems, use data to understand them, and make actionable recommendations.

If you ask almost any data analyst, they’ll tell you that the biggest chunk of their time is spent cleaning and preparing data — getting it into a form that’s usable for reporting or analysis. Ironically, I don’t have any actual data about how much time that process consumes, either personally or for the profession as a whole, but I’d guess that the time spent on acquisition and transformation of data outweighs actual math, statistics, or coming up with recommendations by a factor of five to one or more.

Over time, both personally and as an organization, you get better at capturing and preparing data, and it eats up less and less of your time. I’d characterize the time I’ve spent at Basecamp as being four fairly distinct phases of increasingly greater sophistication in terms of how I prepare data for analysis:

  1. The CSV phase: In my early days at Basecamp, I was just happy to have data at all, and everything was basically a comma separated value (CSV) file. I used `SELECT … INTO OUTFILE` to get data from MySQL databases, `awk` to get things from log files, and the ‘export’ button from third party services to get data that I could then analyze.
  2. The R script phase: After a month or two, I graduated to a set of R scripts to get data directly into my analysis environment of choice. A wrapper function got data from our MySQL databases and I wrote API wrappers to get data from external services. Our first substantial automated reports showed up in this phase, and they were literally R scripts piped to `sendmail` on my laptop.
  3. The embryonic data warehouse: Eventually, a fledgling “data warehouse” started to take form — a MySQL instance held some data explicitly for analysis, a Hadoop cluster came into the picture to process and store logs, and we added a dashboard application that standardized reporting.
  4. The 90% data warehouse (today): today a centralized data warehouse holds almost of all our data, every type of data belongs to a documented schema, and Tableau has dramatically changed the way we do reporting. It’s not perfect — there are some pieces of data that remain scattered and analyzed only after cleaning and manual processing, but that’s the exception rather than the rule.

Over the course of this transformation, the time that I spend preparing data for analysis has fallen dramatically — it used to be that I started any “substantial” analysis with two or three days of getting and cleaning data followed by a day of actually analyzing it; now, I might spend twenty minutes getting vastly greater quantities of already clean data and then a couple of days analyzing it far more deeply.

That evolution didn’t come for free — it took substantial investments of both time and money into our data infrastructure. We’ve built out two physical Hadoop clusters, bought software licenses, and poured hundreds of hours over the last five years into developing the systems that enable reporting and analysis.


I used to struggle with feeling guilty every time I spent time on our data infrastructure. After all, wasn’t my job to analyze data and help the business, not build data infrastructure?

Over time, I’ve come to realize that there’s nothing to feel guilty about. The investment in our infrastructure have paid dividends many times over: in direct time savings (mine and others), in greater insights for the company, and in empowering others to work with data. In the example analysis case I described above, the transformation infrastructure saved a day or two of my time and delivered a better result to the business; I do perhaps thirty or forty such analyses per year. That makes a few weeks or even months of total time spent on those investments look like a bargain.

I often hear people argue that “investing in infrastructure” is just code for giving in to “Not Invented Here” syndrome. The single biggest impact infrastructure investment we’ve made was actually abandoning a custom developed reporting solution for a piece of commercially developed software. Just like any sort of investment, you can of course spend your resources poorly, but done properly, investing in infrastructure can be one of the highest returns you can possibly achieve.

Seth Godin had an excellent take on the topic recently:

Here’s something that’s unavoidably true: Investing in infrastructure always pays off. Always. Not just most of the time, but every single time. Sometimes the payoff takes longer than we’d like, sometimes there may be more efficient ways to get the same result, but every time we spend time and money on the four things, we’re surprised at how much of a difference it makes.


I recently wrapped up a fairly large infrastructure project at Basecamp, and my focus is naturally swinging back towards focusing more exclusively on the core of what I do: analyzing data. For the first time, however, I’m moving on from an infrastructure project without much guilt about whether it was an investment worth making. Instead, I’m looking forward to reaping the dividends from these investments for years to come.

Why I stopped paying attention to industry news

A couple of years ago, I did an experiment: I kicked sugar for three months. I’d have whatever naturally occurred in foods, but I wouldn’t eat anything with added sugar. The goal wasn’t to eat like this forever. I just wanted to know what it felt like to get all that sugar out of my diet. How would I react? What would be different? Would I like it?

The short answer: I felt great. I had way more energy, more balanced days, better mental clarity. But the most surprising outcome came when I reintroduced extra sugar into my diet. During the sugar fast, I wasn’t eating apples, but I tried an apple again. And wow, did I feel it. A sugar high from an apple? That was an eye opener. Even today, with my just-a-tad-of-sugar diet, I can feel the effects of the sweetener in ways I never could before.

I realize this isn’t a health magazine — so why am I talking about sugar? The food detox inadvertently got me to try cutting back on something else I was unknowingly overdosing on: industry news.

Up until about a year ago, I read industry news religiously. I’d load up Hacker News a few times a day, clicking away on the top-voted stories. I’d head over to Reddit and do the same thing on its tech-news subreddit. If I saw something on Twitter linking up a tech-news story, I’d be all over it. Clickity, click click click. I was a tech-news binger.

Then, last summer, I stopped. Cold turkey — just like when I stopped sugar. I had just reached the point at which I could feel an unhealthy level of toxicity piling up inside of me. I felt myself getting too involved, too absorbed, and a bit too anxious about what I was missing, and about what I knew or didn’t know, but thought I should know. I was checking Twitter too often and reloading sites too often. If someone told me about something I hadn’t heard of, I felt like I should have already known about it. Industry news was becoming an addiction.

The first couple of weeks after I cut the cord were challenging. My mind was craving the latest on tech as if it were a substance. While I could steer clear of the tech-news sites, it was difficult not to get hit by friendly fire. I was still on Twitter reading non-tech banter, but then a tech story would suddenly appear in my stream and that uneasy feeling would strike.

Finally, after a few weeks, I began not to miss the news. Whenever I’d see a headline on Twitter, or see people I follow chatting about some new company or technology, I felt a little disgust. It was similar to how I had felt when I saw people gorging on decadent desserts after I’d kicked sugar: It made me sick. So I came up with a new ritual. Every time friends tweeted about tech, I’d use Tweetbot to mute them for 30 days. Eventually my stream was cleansed of all the content I was trying to avoid.

The incredible thing is that a few months into the industry-news detox, I felt better not only mentally, but physically, too. My mind wasn’t on edge, waiting for the next big thing to hit. I was calmer, I found myself with more time, and I was far more focused on stuff I could control, like my product, my company, my person, rather than stuff I couldn’t, like the next “Basecamp killer” or some hot new startup.

It’s now a year later and I still don’t read industry news. Sometimes I’ll accidentally run into it. Sometimes someone will mention something to me wondering whether I’ve heard of it. I’ll often say no and ask for details. And then he or she will tell me about it in a way that’s actually useful, not sensationalized, as most coverage of new things is. I don’t feel disconnected. In fact, it’s quite the opposite. It’s no longer just empty calories: I eventually hear about what’s really important.


Originally published in Inc. Magazine.

Be sure to check out what we’re up to over at Basecamp.