You’re reading Signal v. Noise, a publication about the web by Basecamp since 1999. Happy !

Emily Triplett Lentz

About Emily Triplett Lentz

Lover of bluegrass, mockumentaries, puppies, and food trucks. Her grandma is a clown.

Our favorite stuff

Emily Triplett Lentz
Emily Triplett Lentz wrote this on 4 comments

A few weeks ago, via Know Your Company , we asked folks at Basecamp what brand-name items they couldn’t live without. (We have strong feelings about yogurt, and Chicagoans are extremely serious about their skin care regimens.) Here’s what everyone said:

Emily Triplett Lentz, Support: Ha! I’m sure I could live without my favorite stuff. But I’m glad I don’t have to.
Hearos earplugs. I’m a light sleeper, so I’ve tried lots of different kinds. These expand fully and block a lot of noise. I probably get at least an hour or two more of sleep with them in.
Dreaming Cow yogurt. The flavors are unusual, like blueberry cardamom. They’re fatty but not too sweet. I have one every day.
Burt’s Bees lip balm—the original kind, with the peppermint oil in it. Hurts so good.


Mig Reyes, Designer: My moisturizer game on fleek:
Aquaphor
CeraVe
Eucerine


Shaun Hildner, Video Producer: Aquaphor—I’ll get almost anything in a generic, but Aquaphor.


Wailin Wong, Reporter: Like Mig, I take my moisturizing regimen very, very seriously. CeraVe and Aquaphor all the way. Also in the realm of personal care: Mario Badescu Lecithin Nourishing Shampoo; Cetaphil cleanser; Clear Care or PeroxiClear hydrogen peroxide contact lens solution (every drugstore brand I’ve tried has burned my eyeballs); bareMinerals Original Foundation; Glide floss.
My iPhone, I guess. My Zojirushi rice cooker. The New York Times. The Bobeau sweater. My Uniqlo capri jeggings. That’s right. NAME-BRAND JEGGINGS.


Ann Goliak, QA: I’m real big on skin care products for my face—Cetaphil face wash, Kiss My Face sunblock, Clinique and Philosophy lotions, and of course, Aquaphor.


Andrea LaRowe, Admin: Saucony running shoes. I’ve tried soooo many other brands, but I always end up with yet another pair of Sauconys.


JorDanée Key, Support: Right now it’s So Delicious’s brand of coconut milk. It’s the only coconut milk without a carcinogen preservative. ... Thankfully Costco carries it in bulk.


Natalie Keshlear, Support:
Nike shoes for running.
Klean Kanteen for water.
Happy Socks for happy feet.
WildFang anything.


Taylor Weibley, Ops: Arcteryx jackets. They are expensive but they are also very comfy, durable, well-fitting, and they do their job well. (Wait for summertime sales.)
Costa sunglasses are great when you are out on the water. Their customer service has been good too.


Jason Zimdars, Designer: Upon reflecting on this question I realized I don’t have very strong brand loyalty. I suppose one thing I never compromise on is my Converse Chuck Taylor All-Stars. Been wearing them since I was maybe 9 or 10 years old and they’re still my go-to shoes today.


Dan Kim, Programmer: The only product I can think of that I would never switch from is my Mac. Not Apple broadly, but Macs specifically.
Cars, phones, clothes, food, whatever else brands—I have preferences, but those are all pretty negotiable. But I can’t see myself ever switching from a Mac.


Tony Giang, Support: I have minor brand preferences (Nikon cameras, EVGA graphics cards, Iron Edge gym equipment etc.), but there aren’t any brands that I couldn’t just drop for another.
Being disloyal means I can try out new things without feeling tied down. It also means I probably end up spending more money than I should when I want to try ALL THE THINGS.


Tom Ward, Programmer: I can do without almost anything, but these are the few things I’d go out of my way to get hold of:
Dorset cereals Simply Nutty cereal
Arm & Hammer baking soda toothpaste
Body Shop shower gel


Eileen Uchitelle, Programmer:
Stoneyfield French Vanilla Whole Milk Yogurt—all other yogurt is inferior
Apple products—MacBook, iPhone, iPad
Klean Kanteen Water Bottle
Patagonia outdoor everything—laptop bag, rain jacket, down jacket
And I almost forgot that the one thing I probably can’t live without are my boots. Made by Timberland, awesome construction, even though they aren’t waterproof my feet never get wet. I’ve got a brown pair and a black pair. I wear them all the time with everything and anything.

A New Year's theme: More questions. Less me-talk.

Emily Triplett Lentz
Emily Triplett Lentz wrote this on 7 comments

I asked a friend if she makes New Year’s resolutions. She doesn’t, but she sets a theme for the year. Hers for 2015 is “New”: new places, new activities, new patterns.
The idea of a theme resonates with me. Having never excelled at the “This year, I will ABC” (or, more commonly, if I’m being honest: “This year I will not XYZ”) style of resolution-making — an efficient way to set oneself up for disappointment and guilt — a theme seems gentler, more like a guideline, less like a test to pass or fail.
To that end, my theme for 2015: Questions. And not just asking more of them — asking them instead of talking about myself.
I have the regrettable habit of hijacking conversations. A friend will tell me she’s going to Costa Rica; my instinct is not to reply “How exciting! When? What are you planning to see?” but to announce that I’m going to Belize. A coworker will IM that her cat is an asshole; I’ll volley with a story about my asshole dogs.
It’s shameful. Not to mention a real conversation killer. I might never have noticed, were it not for the way this communication style can shut down otherwise potentially fruitful discussions. What else is there to say when a programmer assists with a challenging case, and rather than ask how he arrived at the solution, I mention this reminds me of another challenging case I once had? Nothing. I learn nothing. And possibly come off as a narcissist.
The “questions” theme requires actual repression of a real instinct. I’m OK with that; it’s a lousy instinct. The idea is that by catching myself often enough, asking questions first will become the new habit.
I’ve already started experimenting with it: biting my tongue when I start to prattle on, asking a meaningful question instead. When a teammate brought up her issues with dairy, I fought the impulse to talk about me and wheat. And whaddaya know — I learned something new about lactose intolerance, and gained insight into the life of a person I care about.
Beats being an ignorant narcissist.

How Basecamp helped the Golddiggers get our act together

Emily Triplett Lentz
Emily Triplett Lentz wrote this on 1 comment

My relay team goes by the name “Alaska Golddiggers,” because race officials frown on us calling ourselves the more accurate “Team Shitshow.”


For a group of otherwise competent women, we’ve managed to screw up a lot during our annual participation in the Klondike Trail of ’98 International Road Relay, a 10-leg, 175-kilometer race that follows the trail of the gold rush stampeders from Skagway, Alaska to Whitehorse, Yukon. Past oopsies include failing to renew passports on time, forgetting our running shoes, traveling with 11 people on an RV that sleeps 8, misestimating the correct start time so our final runner doesn’t have a finish line to cross, and filling the RV’s holding tank to capacity and then some. (Glad you asked — why yes, that is as gross it sounds!)

Half of the team in 2010. If I recall correctly, the ‘K’ in ‘YUKON’ is slightly crooked because we accidentally pulled it off the sign.

We’ve always planned the event either via email or our Facebook group, which worked OK, although details always inevitably fell through the cracks. This year we switched to Basecamp, and the consensus was that planning went much more smoothly. (Full disclosure: Basecamp sponsored us this year, so I didn’t have to work too hard to convince anyone to get on board. Thanks Basecamp!)
We used a to-do list to discuss and assign race legs — they vary from 9 kilometers but steep to 25.6 kilometers but relatively flat. Another to-do list helped determine what everyone would bring to the pre-race washers tourney fundraiser, and yet another served as our packing list. (Item #1: Passport!!!)

We used the hell out of discussions, and it was so nice to have everything in once place, to refer back to: Who is bringing camp chairs? Don’t buy mint; I have some in my garden! What is everyone’s drivers license number to provide to the RV rental company? No, don’t make hummus; we always bring a ton and no one ever eats it.

“I think one one of the coolest things about this year was just how absolutely stress-free everything was,” one teammate said. “I think a lot of the advanced communication set us up to understand our boundaries, how things would work, and to get to know each other in some cases. When it came time for the actual road trip it was like pushing play and just sitting back.”

Perhaps much of that is that after six Klondikes we’ve begun to learn from our mistakes, but Basecamp also definitely helped everyone stay on the same page. We still emailed and texted a bit, but for everything we needed a record of, it went in Basecamp. Of course there were still a few bumps in the road — we neglected to outfit our leg #1 runner with a timing chip; we got rained on a little. Whatever. We still had a blast, and it was the easiest, most relaxed trip we’ve had to date.
And no one felt guilty wasting any hummus.

Our favorite recent reads on the web

Emily Triplett Lentz
Emily Triplett Lentz wrote this on 1 comment

Each week, Know Your Company asks everyone at Basecamp a few questions, including one that helps us learn more about each other. Last week’s prompt was “What’s one great read on the web you’ve come across in the past month?” We enjoyed reading one another’s recommendations so much we wanted to share the results here!

Javan Makhmali, Programmer:
Love People, Not Pleasure – http://www.nytimes.com/2014/07/20/opinion/sunday/arthur-c-brooks-love-people-not-pleasure.html
Dan Kim, All-purpose:
This Paul Graham article from way back in 2007, titled “Stuff”. It’s a great essay on how we have way too much stuff, and how it corrodes our lives.
http://www.paulgraham.com/stuff.html
In my constant efforts to be as minimalist as possible, this article really nailed it.
Chase Clemons, Support:
This story on houses built out of spite was really fascinating.
http://www.citylab.com/housing/2014/07/a-brief-history-of-houses-built-out-of-spite/374331/
James Glazebrook, Support:
When picking fonts for a logo, I was blown away by the story told about this typeface:
http://www.ffmark.com/
Feel free to slam me for conflating the terms “font” and “typeface”, but that’s my level of knowledge. This page did a great job of explaining the background of FF Mark in particular, and the broader type trends that inspired it.
Wailin Wong, Reporter:
I liked “Twilight of the Pizza Barons,” a profile of the founders of Domino’s and Little Caesars that Bryan Gruley wrote for Bloomberg Businessweek: http://www.businessweek.com/articles/2014-07-03/dominos-little-caesars-pizza-founders-contrasting-legacies. Lots of interesting trivia about the two men plus a look at the legacies they’re trying to build now. It’s also a story about Detroit.
There was a line in the story that was so good I read it aloud to my husband (the mark of a really good piece in our household):
“The pizza barons were great at selling pies. Now one wants to save Detroit, and the other wants to save everything else.”
Jason Zimdars, Designer:
I’m fascinated with astronomy and anything that delves into the massive scale of the universe. This piece (from the same site as the popular Fermi Paradox piece the circulated recently) has elements of that with regard to time. It’s light hearted and funny but what I love is how it visualizes time. Starting with a single day the post zooms out again and again to gain perspective. First a week, then a year, then a century, through recorded (and unrecorded history) all the way to the theoretical time before the Big Bang.
I can’t get enough. 
http://waitbutwhy.com/2013/08/putting-time-in-perspective.html
Tom Ward, Programmer:
Here’s a long one and a short one, both from the New Yorker:
First, the best ‘guy walks into a bar’ joke ever: http://www.newyorker.com/magazine/2013/11/18/guy-walks-into-a-bar
Second, food for thought in this criticism of disruption and innovation. I’m still digesting it: 
http://www.newyorker.com/magazine/2014/06/23/the-disruption-machine
Zach Waugh, Programmer:
The Fermi Paradox – http://waitbutwhy.com/2014/05/fermi-paradox.html.
I kept thinking about it for days afterwards, going down many Wikipedia rabbit holes along the way trying to read more about it.
Conor Muirhead, Designer:
I really enjoyed reading this post by Nate Kontny on the stories and character that allow us to connect the dots as we look back on great work:
http://ninjasandrobots.com/dots

The 5 most common Basecamp workarounds

Emily Triplett Lentz
Emily Triplett Lentz wrote this on 16 comments

Basecamp can’t be everything to everyone — when you err on the side of simplicity, you have to say no a lot.

But when customers take the time to explain what they’re looking for and ask whether it’s possible, we want to give them something other than “nope, sorry!” So we end up suggesting a number of workarounds. Here are some of the most common.
To-do templates
Users sometimes miss the to-do list template feature from Basecamp Classic — the new Basecamp has templates, but not to-do list templates. So we suggest the following:

  1. Create a new project template that includes the to-do list you want to be able to reuse
  2. Create a new project from that template
  3. Move the to-do list into the project you need it in
  4. Delete the new project you created from the template.

The Email-In feature also lets you add files, discussions, and to-do lists to your project via email. So you can also keep a draft email with the to-do lists you want to re-use, and email it to your new project.
Sometimes folks have already created a project, but they want to apply a template to it. They can use the same create-a-project-from-a-template/move-things-over/delete-the-new-project process to add content from the template to the existing project.
File versions
This is another popular request from customers, especially those who were familiar with Basecamp Classic. That’s something we’ve explored for the new Basecamp, but at this time there still isn’t a way to upload multiple versions of a document.
In the meantime, you can upload the original file like normal to the Files section. The revision to that file can be uploaded as a comment on that original file (along with any notes about the new version). This way, you keep the original file and the latest version is always in the most recent comment.
Moving a single task from one project to another
You can move whole to-do lists from one project to another, but there’s no way to copy an individual task from one project to another (since Basecamp doesn’t know which destination list to put the task in). But you can:

  1. Create a new list in the original project
  2. Drag and drop the task into the new list
  3. Click the new list’s title, then use the Move feature to put it in the destination project.


Assigning a to-do to more than one person
There’s currently no way to assign a to-do to a group, because users have different preferences about what should happen when the task is complete. Should every person to whom it’s assigned have to check it off? Does only one person need to, for it to be marked as complete? We’re still unsure how or whether to approach that one.
So for now, the best solution is to leave the to-do unassigned, then add a comment to it. In the comment, you can notify all the people who need to be involved.
Sub-projects and sub-tasks
People sometimes ask for a way to list multiple small projects under one larger one, or break a single task into multiple smaller ones. For simplicity’s sake, there’s only one level for projects and to-dos in Basecamp, but there are other ways to organize and prioritize them.
For groups of projects you want to keep together, we recommend using a common preface or emoji. For example, we use “BCX” to name any project that relates to the newer version of Basecamp (“BCX: Android”; “BCX: Support”), which helps us group all those projects together for quick reference. (Check out this video for other project organization ideas.)
And while there are no subtasks, you can add a comment to-do, in which you can outline everything the to-do entails. This video does a pretty great job illustrating all the ways you can organize to-dos in Basecamp.

In some cases, we get enough requests that we ultimately make a change. That was the case with Google Docs, Client Projects and the majority of the improvements we’ve made to our products over the years. When the same issues crop up again and again, it forces us to take a look at how things work, ask if there might be a better way, and take the time to fix it.
Do you use any workarounds in Basecamp? Let us know in the comments!

The person you could be hiring

Emily Triplett Lentz
Emily Triplett Lentz wrote this on 21 comments

Chip Pedersen has been in tech for more than 25 years, 18 in the game industry. He’s led teams at Microsoft and Activision; done R&D for Apple; managed projects for huge brands like DreamWorks, MTV, Discovery Channel, History Channel, the MLB and the NHL.

You should probably hire him.
The catch is that he lives in Minneapolis, and he’s not going anywhere. “I’m just a Minnesota kid who wants to stay here,” he says. “All my three sons were born in different states. We moved back to Minnesota where we’re from. We like it here. We don’t want to go anywhere.”

Chip Pedersen, on a “Silicon Prairie” winter camping trip. “I can work from anywhere and any temperature,” Pedersen says.

“I have had offers to return to the West coast, but I just don’t want to do that.” He says his old Silicon Valley pals keep cajoling him: “‘come back out West; we’ll hire you right now!’ and my wife’s like, ‘no!’ We just celebrated our 25th wedding anniversary, and she said, ‘I’ve moved for you all these years, now can you do it for me and stay home?’ and I said, ‘sure.’”
So home they’ll stay. Pedersen is currently a gun for hire (with his company Golden Gear Consulting), and he likes it that way — he just wishes more businesses were open to the idea of remote work. “You can get great talent and let them be where they are,” he says, “and not have to put up with the cost of living in San Francisco.”
Eric Fleming, a Ruby and JavaScript developer in Jacksonville, Fla., can identify with that. Another father of three, he doesn’t want to relocate for work either. “We like the kids’ school,” he says. “I moved around when I was a kid a lot, and I always thought that it would be great to just settle down somewhere. We’ve established our roots here. We like where we live. The kids have friends and that’s real important for me, to be able to let them have some continuity in their lives.”
Most of the recruiters and hiring managers that reach out to Fleming want him to move, though he’s confident he does a better job working from home. “I can concentrate on my work and there’s no one here to distract me from that,” he says. “There’s no one coming over and tapping me on the shoulder and asking me about something. They may send me a message on Skype or Google Hangouts or something like that, but I can ignore that easier than I can someone coming into my personal space.”
Fleming recently tweeted about being in the market for a new position if anybody has a need for an experienced developer. Predictably, the first reply came from an IT recruiter: “Eric, would you consider moving to Austin or are you looking to remain in J-ville?”
That recruiter — Mark Cunningham, owner of The Bidding Network in Austin — says zero percent of his clients (primarily startups) are open to hiring remote workers. “If we’ve got some crackerjack Java developer who just has something amazing but he lives [20 miles away] in Cedar Park and the startup’s located downtown, we might work something out,” Cunningham says. But for the most part, his clients want to take advantage of the chemistry that results from everyone working in close concert.
“They worry about the loss of synergy, and the collaboration, and then the fires that are stoked from elite software engineers and elite professionals being together face-to-face and what comes from that,” Cunningham says. “That’s where they’re hesitating.”
Fair enough — there’s no denying there are advantages to having everyone in the same room. But when you stack the advantages that come with putting local heads together against the advantages of hiring the best heads from everywhere and collaborating remotely … well, it’s fairly clear where we stand on that.
“Give people the flexibility to work where they feel more comfortable working,” Fleming says. “They’re going to give you better results. It’s better for the company overall.”
Pedersen feels that for the more established companies he’s worked with, the hesitation comes from being stuck in a “face time = work time” paradigm. If you aren’t working onsite, “they think you’re goofing off,” he says.
“I’ve definitely worked at a number of companies where it was about the time you spent there. You may not have been doing much, but you were there. Microsoft was a little bit like that … I had a futon in my office and I would sleep there.”
What will it take for that cultural shift to happen, for companies to begin to allow people to work from wherever they like as long as the work is getting done? A leap of faith, Pedersen says.
“Do a small test,” he suggests. “Try it out. If you can’t find the person you’re trying to hire — if you’ve been looking forever to hire somebody and you can’t find them because they’re not in your region — look for a remote worker. You’re probably going to find an excellent person to meet your needs and get your stuff done. Probably within your budget and faster. Take those leaps when you see the opportunity.”
It comes down to results, Pedersen says. With the teams he manages, he does his best to treat everyone like adults and focus on the work itself. “If they’re getting their stuff done … I’m staying with that person. They got it done last time; they keep getting it done. I don’t care if they live in Venezuela; they’re getting it done.”

Remote Works: It Collective

Emily Triplett Lentz
Emily Triplett Lentz wrote this on 1 comment
Name: Chris Hoffman
Title: Co-Founder, Director of Marketing Strategy
Company: It Collective
Based in: Colorado Springs, Colo.
Established: 2012

What does your company do?
We offer film production and content marketing strategy services. On the marketing strategy side, we work with clients to identify key stories and messages that will resonate with and be shared amongst a target audience — then we help them tell those stories through the creation of that content and the execution of a marketing strategy. On the film side, we produce everything from commercial spots to short films, and just recently finished our first feature-length production — a live concert film for Gungor, an incredibly talented band who have recently been nominated for a couple of Grammys.
How many people work for the company, and of those, how many work remotely?
We are 100% remote. Our business model is project-based, so our team changes in size depending on the number and types of projects we have in house. We went the contractor direction instead of hiring full-time employees for a number of reasons. Primarily, it allows the flexibility to resource the ideal skill sets for each project. Secondarily, hiring individuals who prefer working in a contract setting help us filter out the people who require micro-management — in other words, people who are not suited for a remote work system. The people we hire are used to managing their own time and workflow. We have around 10 team members that we work with on a regular basis.

The editing team works during the peace and quiet of a night shift, 10 p.m.-6 a.m.

Did you start out as a remote company?
We did, and I’d love to say that we had some great strategy behind that decision. In reality, it was made because we didn’t have the startup capital to pay for an office space. We strongly believe in the concept of bootstrapping, and have gotten off the ground without taking on any debt or external capital investment.
We’ve found that we have a great love for hosting face-to-face meetings in coffee shop or home office settings, and that our clients often love meeting in those settings as well. We recently conducted a major client review meeting on a film project in the living room of Andy Catarisano — our Co-Founder and Director of Film Production. We picked apart the final edits over homemade popcorn and cookies. I think our clients loved the experience as much as the final product. It was significantly more effective than presenting in a polished boardroom.
When we need a larger space we rent the tricked-out conference room of a local co-working establishment. Obviously there are occasions when the home office and local Starbucks won’t work, and we don’t pretend that our system will work for everyone. We’ve found a way that works for us to do business without a set physical space, and we aren’t in a hurry to change that.
What challenges did you face in setting up as a remote company?
One major challenge (for those of us that came from a traditional corporate environment) was overcoming the mentality of a 9-5 workday that had been engrained more deeply than we realized. For me personally, it has taken a very intentional effort to ask myself the right questions about my daily activities. I’ve had to learn to look at the day through the lens of, “What is the most high-impact use of my time?” As opposed to, “It’s 3 p.m. — I should be at my desk.”
U.S. work culture has conditioned employees to feel like they are fulfilling their duty to the company they work for by being in their seats for 8 hours in a day. In reality, those employees may or may not be producing anything of value. The amount of time spent at a desk is completely irrelevant to the value and quality of work, and that has been a tough lesson to learn.
What do you see as the major benefits of being a remote company?
The first major benefit is the effect it has on morale, and in turn, the increase in quality of work and dedication to the company. Here is one very practical example of this benefit: Commute time.

I’d love for someone to give me a reason that justifies not giving one of your staff 200 hours of their lives back each year in exchange for zero productivity loss.

Think about how ridiculous it is to demand that an employee sit in rush hour for an hour or more each morning and evening, just to be in by 9 a.m. and leave at 5 p.m. How simple of a switch would it be to allow that team member to work from home until 10 a.m., then arrive at the office in 30 minutes or less with no traffic? That switch translates to well over 200 hours of time given back to that person every year to do as he or she pleases — to spend extra time with family, invest in a personal project, or just take some additional space for decompression.
I’d love for someone to give me a reason that justifies not giving one of your staff 200 hours of their lives back each year in exchange for zero productivity loss. An unwillingness to discuss these types of changes to a work schedule that provide such tangible benefits is just plain arrogance on the part of a management team.
A second huge benefit is the expansion of the talent pool that it provides for us. Instead of being limited to the labor pool within 100 miles of our location, we literally have worldwide talent at our fingertips. We regularly work with a film colorist that lives in Sydney, Australia. The quality of work that we received was vastly superior than anything within our immediate geographic area.
One really interesting thing about working with international teams is that you have almost 24 straight hours of productivity at your disposal. We’d do work in the U.S. on the project, meet briefly at the end of the day with our team member in Sydney before signing off, and then turn it over to him to continue the work. It’s an amazing experience to go to bed, get a great night’s sleep and wake up to a project that is further along than when you left it.
The other really major benefit for us is providing the freedom to tailor the work environment to the type of work being performed. An example of this that really stands out to me is on one of our recent projects, which was a feature-length film. Editing a 90-minute film together is one of the most incredibly detailed processes I’ve ever seen, and it requires a huge amount of focus and precision. We worked an amazing team of editors for this project — the kicker was that they preferred to do their editing nocturnally, from about 10 p.m. to 8 or 9 a.m. The world is quiet then — there are zero interruptions and that was their period of ultimate creativity and effectiveness. A remote work environment allowed us to say yes to that request, and the results were outstanding.
Any advice for other companies who are considering going remote?
The thing about remote work is that it magnifies existing dysfunction in the workplace. An organization with a highly functional team and a deep understanding of role clarity and how to work together in an effective manner is going to have a much easier time transitioning to a remote work structure. A dysfunctional team is going to have a much more difficult time making that leap, because the freedom of working remotely magnifies those inefficiencies.
A physical office space has long been used as a safety net for managers to push the the messes of their team dynamics under the rug as opposed to addressing them. Being able to walk down the hallway every 15 minutes to micromanage employees can (sometimes) cover up poor hiring decisions. It can compensate for a failure to plan. It can also provide a false sense of security for a manager who needs to micromanage to feel effective in their position. Working remotely immediately removes those safety nets and exposes the true functionality of a team. If you’re thinking about making the leap to a remote work environment, it’s important to ask these questions about your team and be very honest in your answers.
Visit It Collective.

The feature that almost wasn’t

Emily Triplett Lentz
Emily Triplett Lentz wrote this on 9 comments

It took more than a year and three distinct attempts to get Google Docs in Basecamp ... and still, the damn thing almost didn’t get built. Why was it so hard?

We knew we needed it. Integration with Google Docs was a super-popular feature request, and usage in general is on the rise. Since Basecamp is a repository for everything project-related, it made sense to show the same love to Google Docs we show to any other type of file you can store in a Basecamp project.

Problem was, we don’t really use Google Docs ourselves. And we’re kind of notorious for scratching our own itch and not building shit we don’t need. It’s absolutely the exception that we would create a feature we didn’t plan on using. (For years, to-dos in Basecamp Classic didn’t have due dates, because we just work on things until they’re shippable. It wasn’t until enough customers hollered at us that we eventually added them.)

“We know tons of our customers use Google Docs; they have to,” says Jason Z. “Everybody’s using Google Docs. So we know it’s useful, we know people are asking for it all the time. There just comes a point where we have to figure it out.”

Shortly after launching the new Basecamp in March 2012, a small team explored what it would take to link to Google Docs from Basecamp. “We started with a little experiment to see whether the tools Google provides are enough to do basic integration,” said Jeremy, the programmer on that first spike. The goal was to be able to “pick a file from Google without having to commit to deep integration that changes the way Basecamp works.”

Google’s file picker made integrating with Google Docs easy, but rendered switching between accounts (if you’re signed in as one user and need to sign in as someone else) nigh on impossible. And we got hung up on what to do about permissions: Our choices seemed to be either allowing anyone who had the link to edit the document, or letting Google handle permissions and suffer the nasty flow and UI that resulted (more on that later).

With the account switching problem, our choices were to wait for Google to improve their tools, or scrap that and find some other way to integrate — i.e., roll up our sleeves and build our own picker. “That led to a waiting game,” Jeremy recalled: “if Google’s own tools got good enough that we could use them, then we’d have an easier time integrating.” So we punted.

Nearly a year later, a different group took a second look. While there still wasn’t a straightforward path for switching accounts, Javan experimented with a ton of different parameters and landed on treating authentication as a separate, first step to lead into the file picker, using Google’s JavaScript client.

What a Basecamp user sees before signing into Google
When a user is signed into a different Google account, they can sign out and choose which account to link to Basecamp.

Managing the two steps separately gave us the flexibility we needed to resolve the account switching issue, but the permissions demon was still rearing its ugly head. We punted again until we’d have more time to explore it.

Each time we felt like we were getting close, we’d reach the same stalemate. No one knew which of the two options for handling permissions was the lesser of two evils:

  1. Allow anyone with the link to view the document. This route would have meant sharing a Google Doc in Basecamp = changing its permissions so anyone with the link could view and change it. Other tools handle permissions this way; it makes things pretty easy and keeps the UI clean. But it creates a pretty gnarly security concern, in that there’s no way to revoke access later. People no longer employed at an organization might be removed from its Basecamp account, but still have access to proprietary information stored in Google Docs. Or users might share the link with outsiders who could then access and edit the document anonymously. No bueno.
  2. Let Google be the gatekeeper. When permissions are set within the Google account and Basecamp doesn’t mess with them, we get to wash our hands of security concerns. Convenient for us! But it passes this potential morass of access seeking and granting onto our users: The viewer has to be signed into Google, and they need permission to view the document to see the preview in Basecamp. If they don’t have permission, they can request it through Basecamp. They’ll then be directed to a Google page, and from there, the request is emailed to the Google Doc’s owner. When the owner grants access to the document, Google sends an automated email to the viewer with a link to view it. “A lot of us were feeling like this leads to a pretty crappy experience,” Javan says, “because you click on the doc and then you hit this brick wall.”
Step eleventy-bajillion-and-four in trying to preview a Google Doc in Basecamp that you haven’t been granted access to

“I was worried that people wouldn’t understand that, because I didn’t understand it,” recalls Ann from QA. “I did an experiment with the support team where I shared a Google Doc with them … I got all kinds of requests to view the document, because I hadn’t given them permission yet. I was afraid that oh my God, every customer was going to see that.” Adding a private file to a Basecamp project with 150 people on it might generate 150 email requests for access to the file. That was too big of a burden to pass along to customers.

The temptation was to punt a third time — only that was no longer an option. “We decided very clearly that if we don’t do it this time, if we don’t figure this out, we’re basically saying that Basecamp is not ever going to have this,” Jason Z. says. “Because why would we take a fourth attempt? That would be ridiculous.”

The pressure to “ship or get off the pot” led the team to explore other possibilities, like building a folder system that would copy Google Docs into a Basecamp project folder on Google Drive, or using Box.net’s Google Docs integration. We finally started to wonder whether the people who wanted Google Docs in Basecamp might already have the permissions thing dialed in. Jeremy chimed in at that point:

Companies switch to Google Apps from company Exchange email and central network fileservers. They “go Google.” Everyone at work is on Google, signed in, and has access to email, drive, calendar, contacts, etc. Google Apps recommends default sharing settings that are a lot like having a old-school central fileserver: newly created files are visible to others by default. There’s no sharing step or permissions-request dance: https://support.google.com/a/answer/60781. This is a golden path. It’s well-integrated and it’s the default when a company goes Google.

That perspective alleviated a lot of the trepidation we had about what users would see when they clicked on a Google Doc — the hope was that if people were already using Google Docs at work, they can probably already access all the links they need to be able to access by default. The access nightmare we envisioned wouldn’t occur if companies’ Google Apps admins were already setting up good defaults, the way Google recommends.

We still weren’t 100 percent convinced we had it right, but it felt good enough for v.1 — to be hands-off, and let the people who use it figure it out (with help, of course). “It’s funny how long the project went on, and in the end, it’s almost simpler than where we started,” Javan says. “But I guess that makes sense.”

“We made a bet on this permissions thing,” Jason Z. says. “We don’t use the feature, so we don’t know. We can’t anticipate what the pain points are going to be here.”

A month or so after shipping, it’s looking like we made the right bet. The majority of feedback has been of the thank-you-so-much-for-adding-this! variety. So far, 56 percent of users are logged into Google when trying to preview a document from within Basecamp, and of those, 91.5 percent already have access to the document they were trying to view. For how much concern there was over whether we were making the right call with permissions, it’s been super quiet. “We were really expecting more confusion, because we were confused,” Ann says. “The people who do use it know how to use it, and I guess we’ve fallen in with their expectations.”

“That’s a super important lesson just in product design in general,” Jason Z. concludes. “You can engineer all kinds of things, and they might be the wrong things if you don’t know. So it’s better to under-engineer and let the pain kind of bubble up organically, than to guess wrong.”

Customer Spotlight: Aardvark London

Emily Triplett Lentz
Emily Triplett Lentz wrote this on Discuss
Name: Christopher Johns
Title: Commercial Director
Company: Aardvark London
Established: 1996
Number of employees: 17
Basecamp customer since: 2004


Tell us a little about Aardvark — what kind of work do you do?
We’ve got two sides of the business. One is the digital agency where we design, build and support the digital experiences for clients. (See examples here.) The other sides is our eCRM platform called Nudge. That’s the back end, effectively, for all our client websites. It manages customer inquires, email marketing, customer communications and customer database and behavioral tracking as well.

Christopher Johns, Commercial Director of Aardvark

You’ve been using Basecamp for a long time, more than 9 years. Do you remember how you first found out about it?
There had been quite a lot of buzz … I think Mike Arrington of TechCrunch had written something about Basecamp. At that time, we were growing and looking for ways to manage our client expectations and their projects. It seemed like a no-brainer, an easy way for everyone to track what’s going on and get customer buy-in as well.
What kinds of problems were you having with managing client expectations?
In what we do, there’s a lot of going back and forth with clients, and various people within various positions. So you might be speaking to the digital marketing person, the head of operations, the head of marketing. Historically, you would have done things via email. You would have sent someone a concept or something, and said “What do you think of this concept?” You’d CC three people on that email, and have three people coming back with comments, some of which are conflicting. Then you start replying to those and indenting your comments on their original comments. Pretty soon, you know what it’s like; everything gets lost. The original sort of thrust, the momentum, of the project gets bogged down in trying to manage the communication between you and these disparate parties.
Clients may not be as technically proficient as you want them to be. My son is 12 and my youngest is three. The three-year-old is very, very capable of using my iPhone and my iPad and doing all of that, whereas my mother is not.
So your clients tend to be older or less technologically adept?
Some of them are, some of them aren’t. What they don’t want to do is have to learn a whole new thing just to work with us. Our job is to make their lives easier. If they have to go and learn a whole new thing in order to just communicate, you’re off to a bad start to the relationship.
Basecamp is very simple. They don’t have to go and log into anything; all they do is reply to an email, and post their comments. And being able to track all those comments coming through, from all of those disparate sources … you’ve got a nice clean audit trail so that if anybody questions it at a later date, you can say, “well, have a look at this. This is what you said on this date.”
Does that happen?
Yeah, it does. Not that frequently.
What kinds of projects have you managed with Basecamp?
We’ve just done a project for Transport for London, the authority that runs all the underground for London and the buses, Boris Bikes, and the river buses as well. We’ve just built a digital sign project for them — you’ll see signs all over London now with these maps on them that have real-time bus departure information overlaid, that’s localized to the location of the digital sign.
With digital signs for Transport for London, it’s about thousands of people all in one location, and how they’re all interacting with that information, and how that sign helps guide them to their chosen destination. So for example, you can’t use colors on a digital sign to indicate a particular stop, because people would be looking around them in the bus station looking for yellow, and that yellow doesn’t exist.

A sample of one of the digital bus timetables Aardvark created for Transport for London

In London, there are literally millions of people who use the buses every day. Millions of people need to know where to go, and digital signs are helping them in that process. It’s a very interesting user experience development process to try to communicate to people via digital signs that are in the real-world environment that have to show complex data and make it simple for all these people to find where they’re going.
What’s your work culture like?
We’re a collaborative culture; we’re a small team. Everyone brings something to the party, and it’s about the respect for what each individual brings to the party that gets the most out of every person working on the team. We’re not a personality-led business. People don’t come to us and say “I want to work with Aardvark because Chris is there.” They work with us because they see the output that we have as a team and they want that for themselves.
I understand you just moved into some new offices?
We are moving, but it’s been delayed. It takes between 60 and 90 days to get fiber installed. We’re moving closer to Transport for London and a couple of our other clients.
We’re changing how we work as well. We just instituted an opportunity for the staff, where they can go and work 25 days per annum from wherever they want to. We have one guy who spent two months earlier this year working out of Peru. If you want to work from home for one day, that’s fine. Basecamp is one of the systems we use that will enable that process to be more effective. At the moment I live in the city with my wife and children and dog, and we’re hoping to move out of London a bit to get a little more greenery. So it’s actually going to help me as well.
Why 25 days in particular?
It’s pretty much an experiment to start with; the 25 days is a pretty arbitrary figure at the moment. If everything goes well, if people like it and they’re motivated and they feel good about the whole thing, productivity is shown to be positive, I don’t see any reason why we couldn’t do more.
Visit Aardvark.

Everyone on Support

Emily Triplett Lentz
Emily Triplett Lentz wrote this on 9 comments

Earlier this year, Y Combinator partner and Wufoo founder Kevin Hale came to speak with 37signals about how to design software users love. Here’s the talk he gave at UserConf 2012, that inspired our support team to invite him to our company-wide meetup:

Kevin is big on making everyone at the company do support, and how that informs what he calls “support-driven development.” When everyone has to answer customer emails, they’re more invested in improving the product for the people who pay for and use it.

We’d considered a “5% support” model before, wherein everyone at 37signals would answer tickets one day a month. But it wasn’t primarily because we wanted everybody to get touchy-feely with customers; it was because we were drowning in tickets. We ultimately tackled that problem in other ways — by expanding business hours, hiring a few new people and creating a comprehensive help site. “Everyone on Support” no longer seemed imperative.

We were missing the main point, though. Putting designers and programmers and everyone else in direct contact with customers isn’t about putting out fires; it’s about fire safety. It’s about having the kinds of conversations that lead to better products in the first place.

The idea is hardly novel; plenty of successful companies (Amazon, Olark, Zappos) train every employee to work one-on one with customers. Paul English, CEO of Kayak, told Inc. Magazine:

The engineers and I handle customer support. When I tell people that, they look at me like I’m smoking crack. They say, “Why would you pay an engineer $150,000 to answer phones when you could pay someone in Arizona $8 an hour?” If you make the engineers answer e-mails and phone calls from the customers, the second or third time they get the same question, they’ll actually stop what they’re doing and fix the code. Then we don’t have those questions anymore.

But let’s face it: Few people are going to jump at the chance to answer tickets if they don’t have to. (“I don’t know how you guys do this every day” is a common refrain among developers who jump in on support.) Still, no one denies it’s good for them, or for the company. Ultimately, leadership has to believe it’s valuable, and be willing to get their own hands dirty too.

Fortunately, that’s the case here — after all, Jason and David used to answer all those emails themselves, so it was familiar territory. Shortly after Kevin’s talk, Jason asked everyone (via Know Your Company) “Is there anywhere we’ve been all talk and no action?”

The earful he received from the support team was what it took to finally get “Everyone on Support” implemented. Ann hopped on the case and assigned everyone in the company a “buddy” on the support team, someone they could go to with questions and who could proofread their replies if necessary.

We’ve been at it about eight months now. We still have some kinks to iron out — sometimes we’re fully staffed, for example, so the “EOS” person doesn’t have a lot to do — but for the most part, we’re pretty tickled with the results. A few discoveries we’ve made so far:
1. It’s an incredibly useful training tool. The fastest way to familiarize a new hire with our products is to have them answer questions from customers. Nathan, who joined us in July, says that he absolutely learns something new with every EOS shift. “As a new employee, that was vital to helping me understand what we’re doing and how we’re doing it. Seeing how some of our jobs get stuck in the queues (avatar uploads, project exports, daily mailers, etc.) really helped tie some of the things I see in Ops to what our customers are doing.”
2. Long-standing problems get fixed. It’s not uncommon for a designer to improve the way something is worded on our website during their EOS shift, or for a programmer to spend some time squashing a bug based on an interaction with a customer. Especially when we have sufficient coverage for the day anyway, that’s been a fantastic use of the EOS shift person’s time.
3. The workflow process has applications outside support. “My ‘real’ job is so scattered,” says Andrea, our office manager. “I’m usually working on 2-3 issues at one time. When I work EOS, I try to focus on one thing at a time, resolve. Focus -> resolve. Focus -> resolve. Applying that mentality to my real job helps me feel less scattered.”
4. It reminds us why we’re all here in the first place. Our customers are the reason we exist as a company — the reason we get to do the work we love and take home a paycheck for it. That can be easy to forget if you never interact with them. “Software engineers and designers are often divorced from the consequences of their actions,” Kevin says. Not so if everyone has a stake in making sure the product is a pleasure to use. “Ops can rapidly get detached from the customer, because all we’re doing is keeping the lights on and helping set up new apps,” Nathan adds. “EOS keeps me reminded of why we’re doing that, and how our customers use our products.”
Does everyone at your company have a chance to interact with customers? If so, tell us more about it in the comments.