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

Asking why

Jonas Downey
Jonas Downey wrote this on 7 comments

Last week I asked a question on Twitter: If you have a personal website, why do you have it?

Some people used their site as a hub that collects their online identities. Others liked to fiddle with web tech or writing. Several treated it as a showcase for their professional work, to possibly get a job. Everyone else, it seems, didn’t have a reason aside from a general feeling of obligation.

I think that last group indicates a sea change. In the early days of the web, your site was a big part of your identity. It was one of the best places to share information, prove your geek mettle, and make a little network of fellow weirdos. In 2015, we have a million other ways to do that, so a personal site feels left over from a bygone era — a tiny island adrift in a vast ocean of apps, status updates, and clickbait headlines.

And so, its purpose has become even more vague. People don’t know what a personal site is for anymore, so they go through the motions. They put the same things everyone else puts on there. A giant photo of a city. Something that says “Hi, I’m Dave.” Fancy scrolling effects. A bunch of social media icons. An unintelligible skills chart. A quickly neglected blog.

All these choices are based on assumptions. First, the assumption that you even need a website. Second, that a website looks a certain way and has this usual kind of stuff on it. And third, that some anonymous group of users will stumble upon it and be interested in it.

As an industry, we have this problem a lot. We do things because that’s how everyone else does things. We assume that what’s popular must be good, so we don’t ask questions…we just do it! Even if we’re not that into it.

This is also why you see countless corporate websites that look exactly the same and automatically generated hipster logos. It’s much easier to assume an existing pattern works and reapply it than to dig in and find a deeper understanding of the real problem you’re trying to solve.

But shortcuts like this rarely lead anywhere new or interesting. Why replicate what hundreds or thousands of people already did? The best you can achieve is as good as everyone else. That makes you forgettable.

There’s a simple solution: ask why you’re doing something, and don’t bother getting started until you have a clear answer. This applies to any situation, but in this particular example…

Why should this website exist?

That question leads to more specific questions…

  • What am I trying to get out of this?
  • What’s unique about my story?
  • Do I have anything to say?
  • Why would someone look at this?
  • Why do I want them to look at it?
  • What do those visitors really need to know?
  • What should they do next?

When you work outwards from why, you unlock all sorts of revelations that aren’t about obligatory features or popular trends. You might find that those scrolling effects and skills charts have nothing to do with your story and the outcome you want. Maybe you’ll uncover a parade of new ideas dying to see the light of day. Or you’ll decide your site is just for your own experimentation, and that’s OK too.

If you find no strong reasons for a project to exist, all the better! Kick it to the curb and free yourself to spend time on something else.

Lead Android at Basecamp!

Nick
Nick wrote this on 2 comments
Happy Camper

We’re looking for a programmer to lead us on Android and push us further into the platform. This is a unique opportunity: we don’t hire often! We’ve got a serious foothold in the ecosystem, and we want you to take us to the next level.

Here’s a little preview of Basecamp for Android right now:

We’re happy to welcome applicants based anywhere around the world. Our office is based in Chicago, but our team is spread out over multiple countries and time zones. You can work from anywhere! We’re so serious about working remotely that we even wrote a book about it.

Basecamp offers benefits for the long run, including: 4 day work weeks during the summer, an exercise and CSA stipend, a 1 month sabbatical every 3 years, maternity and paternity leave, and health insurance that covers children, marriages, and domestic partnerships.

Who are we looking for?

We’re looking for someone who lives and breathes mobile, and especially on the Android platform. Fluency in Android’s patterns and APIs is a must. (Half-hearted iOS ports drive us crazy too!) We would love to talk to a developer who has experience shipping applications with a team, or independently on your own projects.

Here are some examples of day to day interactions with our mobile team. One day we might be diving through the Material design spec…

Material Design

...and the next day we’ll be tossing around ideas for an Android Wear prototype.

Android Wear

What will you work on?

You’ll work on our mobile team to support and improve Basecamp for Android, side by side with our other programmers, designers, and QA team that enable our customers to get their work done better on the run.

Here are some fun stats from our app’s usage in the wild. Android is our fastest growing mobile application right now:

Android Growth

Like many others with Android apps, we see a lot of older versions of Android, but we’re not afraid to welcome those users in while experimenting with the latest goodies from Google:

Android Distribution

You’ll join the our team of programmers who work on our Rails and iOS apps. Basecamp is the home of Ruby on Rails, and we’ll be happy to introduce you to our infrastructure. Part of being a programmer at Basecamp is our on-call rotation, where we help fix day-to-day issues for our customers using our products.

We also believe strongly in putting everyone on support, which usually happens around once a month. If you have some experience with Rails, that’s a bonus—but not a requirement.

Happy Camper Call

How can you apply?

We love cover letters. They’re a great way to introduce yourself, but don’t be afraid to surprise us in other creative ways too. We want to see what you’ve built and shipped, so any existing applications on the Google Play Store that we could try out would be great to include.

Please email android@basecamp.com saying that you want to lead the Android charge at Basecamp, and we’ll be in touch!

We’ve posted this to our new jobs page too, if you’d like a better link to share: https://basecamp.com/jobs/android

Effort in the Application: sites that got our attention and got Basecampers their jobs

Mig Reyes
Mig Reyes wrote this on 2 comments

We’re really proud of the small-but-mighty team we’ve built here at Basecamp. Hiring is hard. Likewise, landing a great job is hard. In a sea of resumes, effort rises to the top.

Here are a few of the websites and commissioned challenges that helped these Basecampers score their job here. Note: our company was called 37signals before we became Basecamp in 2014.
Ryan Singer (Designer, Product Manager) was one of a few designer candidates that Jason picked in 2003 for a chance to join 37signals to work on client projects. The design challenge? Redesign the Verizon Wireless homepage. Ryan showed a great sense of clarity despite little to no direction, and he’s been at Basecamp ever since.

Jamie Dihiansan (Designer) met Jason early on in his career. 37signals wanted Jamie to apply for a new design position, but he wasn’t ready for it. Years later, timing finally worked out and Jamie applied for a new design position with a carefully crafted letter and a Backpack redesign.

Jason Zimdars (Designer) was quick to respond to this job posting. Turns out, JZ didn’t get the job, Jamie (above) did. Despite that, JZ still had great work and kept in touch. When 37signals had room for a new designer role, we asked him to apply and he came back with the new gold standard in applying to a job.

Ann Goliak (Support, QA) was a librarian when she first came across a Support position on our blog. Two hours later, she shot us an email and quickly forgot about it—she didn’t think she’d hear back. A month later, she heard back from us and whipped up a meaty page on why she’s a great fit.

Nick Quaranto (Programmer) wanted to move back home. Working remotely seemed like the best way to do that. Nick applied to 37signals out of the blue, thinking it was a longshot. But a descriptive site showcasing his passion convinced us otherwise.

John Williams (Ops) was tipped by his brother that there was an ops opening on the 37signals Job Board. John rose to the top with a personal site that gave him an extra edge over all of the other candidates.

Trevor Turk (Programmer) was working as a contractor during a short stint in London when he came across a programmer job posting on our blog. He worked up a straight-to-the-point page to toss his hat in the ring. Turns out, it was everything he needed to do to join the team.

Jonas Downey (Designer) reached out to Jason after he tweeted about a new design role within 37signals. Jonas interviewed, but ultimately didn’t get the job. A half-year later, another design role opened up. Jonas applied again, knocked his design challenge out of the park, and he’s been a happy Basecamper since.

Joan Stewart (Support) was a librarian, a Backpack user, and a regular Signal v. Noise reader. Knowing that Ann was a librarian, Joan thought “if she could work at 37signals, so could I.” She took the time to whip up her own page, and now Joan is a happy Basecamper, too.

Shaun Hildner (Video Producer) was quick to shoot an email to Jason after seeing him tweet that 37signals was looking for a video producer. His reel got him an interview, and his test got him the job.

Mig Reyes—that’s me!—(Designer) dropped an email to Jason looking for a written recommendation when he was applying for a totally different job in Chicago. Jason offered, “would you be up for working with us at 37signals instead?” A few meetings with the team in Chicago and a design test to boot, Mig became the next Basecamper.

Dan Kim (Programmer) was just about finished taking an advanced HTML and CSS class at The Starter League. He emailed Jason if there were any opportunities, but there weren’t at the time. When we started to work on Know Your Company, Jason reached out. Then after a couple of lunches and a test project, Dan became a Basecamper.

Jim Mackenzie (Support, Programmer) noticed he hadn’t seen recent Signal v. Noise posts after updating his RSS reader. Out of curiosity, he visited our blog in his browser and stumbled upon this job post and sent us a strong pitch and some work on why we should hire a stranger from the UK.

Conor Muirhead (Designer) had a coworker mention that Basecamp was hiring a product designer. Considering a job switch himself, Conor pulled the trigger on firing off this email to Jason. Conor’s effort put him into consideration for the job, and he followed it all the way through with his fully thought out design challenge.

James Glazebrook (Support) was tipped by Natalie, already one of Basecamp’s very own Support team members, that we were hiring someone to cover European hours. James had read REWORK before, so he knew we valued applicants going above and beyond. The result? 37 reasons why we should hire him.

Sylvia Chong (Support) planned on starting a food blog with a friend. Knowing they needed a good way to keep track of progress, her friend recommended using Basecamp together. Sylvia loved using Basecamp, so much so that she wondered if there were any jobs here. Luck and timing were in her favor, there was a perfect-sounding spot for her on our Support team. She finished her convincing site a week and a half later, and now we’re glad she’s on the team.

And of course, the original 37signals Manifesto that helped land us plenty of our former clients when we were a web consulting agency.

By the way, we’re hiring a programmer to lead Android and a designer to do brand and marketing. If you’d like to join the team, reach out to us!

Sometimes there really is an easy button

Noah
Noah wrote this on 4 comments

For a long time, I was frankly somewhat dogmatic about the tools I used to analyze data: Give me a SQL connection, R, and my trusty calculator and that’s all I need. If I need to make a report, I’ll just use Rails and HTML. Open source or bust.

For most of my four years here at Basecamp, that was mostly how I worked, and it was fine. I think I was reasonably productive (or at least productive enough to stay gainfully employed). I built a lot of tooling and reporting for the rest of the company, and I did some analyses that I’m proud of. These tools were all I needed, but it turns out they weren’t all that I wanted.

As we’ve grown as a company both in headcount and analytical appetite, I found that I was spending a lot of time working on reporting—dashboards, one-offs, random questions asked in Campfire, etc. This kind of thing is important and vital to a successful company, but it frankly isn’t that much fun to do. Fiddling with the position of charts in an HTML dashboard or typing long incantations to generate a simple histogram just aren’t how I want to spend my day, and I don’t think that’s the most value Basecamp can get from my time either.

So I went shopping, and I bought a license to Tableau. I used it to prepare for a big internal presentation, and then I got the server version to use for all future reporting on features, usage, our support team, even some of our application health and performance work. I’ve used Tableau at least a little every day since then — when talking about mobile OS fragmentation in Campfire, when reviewing the year our support team had, and as a replacement for parts of our Rails-based internal dashboard app.

There’s absolutely nothing that Tableau can do that I couldn’t do before, but that’s exactly the point: it lets me do the exact same stuff much faster, cutting down on the parts of my job that aren’t the most exciting and leaving more time for more valuable work. So far, the things I use Tableau for take less than half as long as doing them with my more familiar toolset, and I end up with the same results.

I still use R, SQL consoles, and my HP-12C every single day, and I commit to our Rails dashboard app almost every day. If you’d polled Basecamp six months ago and asked who was the most likely to be using Windows and endorsing the use of expensive enterprise software, I’m pretty sure I would have been the last person mentioned, but here I am.

Admitting that my dogma was wrong and spending a relatively small amount of money on a great tool means that I get to use those other tools that I know and love on more interesting problems, and ultimately to have more of an impact for Basecamp and our customers.

One of Basecamp's Water Coolers is a chatroom dedicated to pets

Kristin
Kristin wrote this on 8 comments

As you can see from Dan’s post, lots of us are animal lovers. Back when I lived in Chicago, a few of us would take turns hosting a workday that we would call “Bring Your Work to [Pet’s Name] Day.”

When Ann, Sam, and Trevor came to my apartment for “Bring Your Work to Clementine Horsetooth Day,” we worked from my couch and enjoyed the occasional interruption by Clementine, my elderly Siamese cat. She strutted around flirting with the newcomers: stretching and yawning and shaking her tail. At “Bring Your Work to Hector Day,” a bunch of us holed up in Sam’s loft with his sweet tabby and ordered a ton of Indian food. After work, a few of us got drinks at the Skylark before heading home to our own pets.

Online, we got to know everyone else’s pets from our Campfire room, All Pets. All Pets is a place to blow off steam, to take a break from work, and to connect with coworkers who may live on another continent.

And so, when Clementine died last November I knew my coworkers would be supportive, but I didn’t realize how much so. Not only did our office manager, Andrea, send flowers on behalf of the entire company, but I also received a whiplash of IMs from many people expressing their love and support. Ann (who doubles as World’s Best Catsitter for many Basecats) was especially supportive, in part because she had recently gone through the loss of her own Basecats. And then, a week after Clementine’s death, I received a condolence package from Berliner Natalie containing this amazingly succinct mug.

When I think of the average office dynamic, I don’t think of this kind of camaraderie. Maybe it’s because our figurative water cooler is a silent, opt-in chat room filled with adorable animals that we’re able to connect more earnestly than if we were at a literal cooler. Maybe it’s because we’re all abnormally obsessed with animals, but All Pets isn’t our only Water Cooler. There’s All Parents, All Nerds, All Comics & Movies, among others. Nonetheless, there’s nothing at Basecamp, not even an ocean or two, that keeps us isolated from one another.

In Memory of all the pets we lost at Basecamp.

Strategies for getting feedback (and not hating it)

Jonas Downey
Jonas Downey wrote this on 7 comments

Recently my team has been working on core improvements for Basecamp. We planned to move quickly on a range of projects, and we wanted to make sure everyone at the company stayed in the loop. Plus, our company is full of smart folks who know the product inside and out, and we were hoping to use that hive mind to our advantage.

That’s easy when you have 5 or 10 people, but it’s challenging with 45. We had to share a lot of info and avoid pestering everyone in the process, so we began experimenting with a few new ways of working. Some of ‘em worked, others…kind of worked. Here are a handful of the strategies we tried the hard way.

Make screencasts for easier reviews.

No matter how many times you’ve done it, asking people for feedback is a harrowing ordeal. They’re busy working on something else, and you’re requesting their precious time and attention.

We wondered: what’s the most effortless way to communicate what we’re working on? Long written messages or storyboards take a lot of time to wade through. So instead of that, we started making 3-5 minute screencast demo videos for each project-in-progress. We share these videos with everyone at the company and ask them to comment. They’re friendly and easy to watch.

In each demo, we talk about the motivation behind the project and what we’re trying to accomplish. We explain how our solution addresses those things. We also mention weak spots or details we’re not sure about.

Here’s an example:

These videos helped quell broad questions like “why are we even doing this?” because they demonstrate that we’ve thought through the big picture stuff. As a result, the criticism we receive is more specific and actionable.

Sidenote: if you do this, you’ll have to get comfortable recording screencasts. After about 5 of them, you get the hang of it. The first step is accepting that yes, your voice is weird, and your face is kind of weird too, and wow, you’re not good at this at all, are you?

Work in the open.

A few years ago, Ryan wrote about designing in the open. We took that to its logical extreme and left our work wide open for anyone in the company to see at any time. That meant having our ongoing projects (in Basecamp) visible to everyone, and sending out weekly status updates about our work in progress. We call these heartbeats.

For feedback purposes, the heartbeats proved more successful than the open project. The open project is like a dirty workroom — people feel bad wandering in and criticizing what you’re doing while you’re doing it. (Plus we’re a remote company, so the workroom is full of people who aren’t wearing pants.)

That said, it’s still nice to let people peek if they’re curious about what’s going on. It also leaves a chance for the occasional helpful comment you might not have expected.

Seek out people who have different perspectives.

Getting the truth isn’t always as easy as mass-emailing people. You might actually have to talk to them. Sorry, fellow introverts!

We’ve made a concerted effort to chat with people outside our immediate development team, like our customer support people, data analyst, QA folks, and anyone else in the company who might look at the problem from a different angle. Sometimes they don’t speak up on their own, but if you reach out personally, they’ll almost certainly mention things you never considered.

Decode vague comments.

How many times have you heard (or said) stuff like this?

"This one looks more readable." 
"I like how this one is clean and simple." 
"This version makes your eyes jump to the important part of the page." 
"This seems like it’s the most usable." 
"This solution might be too noisy." 

This feedback isn’t necessarily bad, it’s just incomplete. Words like clean, usable, and noisy don’t have much meaning. They roughly suggest something about hierarchy, contrast, and spacing.

When we get feedback like that, we dig deeper and ask for clarification. If something looks more readable, why? What about the design is better? More whitespace? Typeface pairings?

Once you unravel the real issues, you’ll know which direction to go. You’ll also get better at offering suggestions to others. Instead of saying, “hey this design looks bad and weird,” you’ll say, “this doesn’t fit in well with our usual styling.” Details like that give your colleague a hint about what they need to improve.

Emotionally separate yourself from your work during critiques.

If you’re working on a project you care about, you’re invested. Sharing your work puts your ass on the line, and hearing a negative reaction will sting. (Admittedly, it’s even harder in front of the whole company. Your ass is on all the lines.)

But the only way to make something great is to recognize that it might not be great yet. Your goal is to find the best solution, not to measure your personal self-worth by it.

Furthermore, most people are reluctant to tell you what they really think. Got negative feedback? Cool! You just succeeded at finding the truth. That’s a win in itself.

When it’s time to share and evaluate what you’ve done, try to put your emotions and sweat equity aside. If you can manage this, you’ll be able to debate the ideas logically instead of emotionally.

When nobody responds, you probably haven’t nailed it.

We noticed that people rally around an obviously good or bad solution. If a solution is strong, you’ll hear about a few minor nitpicks, usually interspersed with an excessive quantity of happy emojis. If it’s clearly bad, a few honest folks will call it out (with not so many emojis.)

When the team is indecisive, or worse—silent—there might be bigger underlying issues at stake. The best way to move forward is to get the whole team together and air it out. Get on the phone, or Skype, or have a meeting and chat in person.

We did this with a project that wasn’t going so well. We were creatively stuck, but we’d been trying to work through it individually. When we reconvened as a group, everyone had a chance to voice their concerns and agree on what to do next.

Make the call.

What happens when everyone disagrees? You might have multiple viable ways to proceed and no definitive answer on any of them.

Now it’s up to you to weigh everything you heard. How much time do you have left to make changes? Which solution do you feel strongly about? Does someone else feel strongly when you don’t? Is there a compromise version, or another option you haven’t considered yet?

The answers here are always different, but one thing remains the same: it’s up to you. It’s tempting to pawn off these decisions to other people, or wait for a consensus to appear, but it’s better to choose a direction than to keep spinning your wheels trying to please the group. Making the call has the side effect of drawing out people who were on the fence — if it’s the wrong call for some reason, they’ll speak up before it’s too late!

Don’t be embarrassed when things don’t work out.

Not every project is an immediate success…or even an eventual success. Out of our last 10 projects, 2 didn’t go smoothly. The first one shipped after we took a break and regrouped. We shelved the second one entirely, because we tried numerous approaches and there was no clear path forward.

Admitting defeat doesn’t feel great, but it’s far better than trudging ahead with a design that simply isn’t working. Who wants to ship and support something like that?

Return the favor.

Try offering thoughtful critiques of others’ work. Be kind, honest, and specific. It’s surprisingly difficult to do!

If you’ve been in the game for a while, mentor the younguns. Help them improve and share the feedback love. Teach them to screencast so they’ll get used to their weird voices and faces too (eventually.)

Do you have to love what you do?

Jason Fried
Jason Fried wrote this on 16 comments

Attend enough startup conferences or listen to enough motivational speakers and you’ll hear one piece of advice repeated over and over again: You’ve got to love what you do! If you don’t love what you do, you might as well stay home. No less a giant than Steve Jobs famously told Stanford’s 2005 graduating class, “The only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle.”

I don’t buy it.

There’s nothing wrong with loving what you do, of course – I just don’t think it’s a prerequisite for starting a business or building a fulfilling career, let alone doing great work. In fact, I think it’s disingenuous for really successful people to put so much of the focus on love, just as it’s disingenuous for really rich people to say money doesn’t matter. People tend to romanticize their own motivations and histories. They value what matters to them now, and forget what really mattered to them when they started. It’s human nature, so it’s an easy thing to do.

The way I see it, many great businesses and important innovations are actually born out of frustration or even hate. Travis Kalanick and Garrett Camp, the co-founders of Uber, didn’t start their ride-sharing service because they loved transportation or logistics. They started it because they were pissed off that they couldn’t get a cab in San Francisco. Kalanick may love running Uber today, but he really hated not having a way to get home. A random brainstorming session one night in Paris turned that frustration into the seed of a multibillion-dollar company.

I talk to other entrepreneurs all the time, and many of their companies sprang into existence for similar reasons—because the founder wanted something that didn’t exist or scoped out an opportunity to do something better than it had been done before. Love for their subject matter may or may not play a role in their stories, but hate for the existing options, along with strong opinions about how things could work, does and is a much better predictor of success.

My own career is no exception. Back in the mid-’90s, I was looking for a simple tool to keep track of my music collection, and all of the available programs seemed bloated and unnecessarily complex. Those are two things I hate, so I set out to make my own tool and eventually released it under the name Audiofile. I didn’t love music collecting. I didn’t even love software development. (I was just learning it at the time.) And I didn’t have any aspirations to run a software business – I just saw a need, and I filled it. Nothing wrong with that. A similar situation led me to start my current company, Basecamp.

Truth be told, even today I don’t always love what I do. The paperwork, the reporting, the day-to-day minutiae that come along with responsibility for a large and growing company – none of those things make me swoon. Yet I’d still rather be running Basecamp than doing anything else. I think I’m good at it, every day I get to do challenging, creative work, and I continue to find making better project-management tools a worthy and rewarding cause. It’s also a real pleasure to work with such amazing people as I do every day of the week.

If I were giving a motivational speech, I’d say that, if you want to be successful and make a real contribution to the world, you have to be intrinsically motivated by the work you do, and you have to feel good about spending your days on it. Love might grow – and it’s a wonderful thing if it does—but you don’t need it up front. You can succeed just by wanting something to exist that doesn’t already.

-

Printed in the February issue of Inc Magazine

IMG_0121.jpg

Comparing warning labels on gym equipment. From the 80s on the left, from the 2000s on the right. The one from the 2000s says a lot more, but the one from the 80s means a lot more.

Jason Fried on Jan 18 2015 10 comments

Basecamp is hiring another Marketing Designer

Mig Reyes
Mig Reyes wrote this on Discuss

We’re looking to hire a Designer to join us at Basecamp to work on all sorts of fun, meaningful marketing projects. The last time we hired for this role was when I joined in 2012. The last time before that? It was Jamie in 2008. We don’t often have openings for design positions like this, so we’re really excited to bring someone new to the team.

Designers at Basecamp are a fun bunch, and we all do a bit of everything. We’re not just setting type, picking Pantone colors, or pushing pixels in Photoshop. In addition to graphic design, designers at Basecamp write tight copy, plan the user experience for marketing pages and apps, and craft the HTML and CSS to bring it all together. We don’t think this makes you a unicorn, or a ninja, or a rockstar. We just think it makes you a well-rounded designer. You may not have all these skills yet, but you’re looking for a place to learn and hone them.
Designers that work on marketing at Basecamp aren’t afraid to sell. Whether it’s getting your coworkers to buy in on a direction you’ve designed, or writing copy that makes it clear why customers should choose Basecamp, you don’t shy away from the role of marketing: selling something worthwhile.

If you were a marketing-focused Designer at Basecamp, here’s some of the work you might have done:

When the new version of the Basecamp app launched, you would have lead the charge on designing a new Help site while teaching the Support team how to write the documentation for it.

When we changed from 37signals to Basecamp, you would have worked on the brand new marketing site for our exciting company change.

You would have suggested that the new name change, along with all of our new coworkers we hired in the last couple of years, warranted fresh business cards. So you made them.

You believed in supporting businesses who have lasted for generations, so you volunteered to design The Distance.

You would have found your own design’s shortcomings and months later, redesigned The Distance to make it faster to update and easier to read.

Over time and if you were feeling adventurous, you’d dive into the world of product design to add useful features including Annual Billing and storage upgrades, because making customers happy and having a positive impact on revenue is a win-win.

You’d go on to create beautiful letter-pressed invoices, because our customers deserve the best in every instance we get to talk to them.

On a whim, you’d swoop in to help Dan and Merissa make t-shirts to hand out at the latest conference we’re sponsoring. Heck, you’d even think of other great conferences and initiatives we should be sponsoring, too.

You’d give our Support team fun ways to write personal notes to customers.

You’d help plan and design the materials that went into Basecamp sponsoring the Pitchfork Music Festival. Dressing up like a camper is both silly and optional. But we’re all fun here, so you wouldn’t have thought it was weird to do so.

Some work you might do once you get here:

You’ll look at billboards like this and ask, “if Basecamp took out a billboard, what would ours say?”

You’ll encounter beautiful wall murals like this and offer, “if donut shops can have great branding and advertising, why can’t Basecamp?”

You’ll also help us make Basecamp.com feel alive and relevant, you’ll learn the ropes of A/B testing and experiment with new designs often for our marketing sites, you’ll craft email campaigns about Basecamp that people actually want to sign up for, and you might even share everything you’ve learned on this blog.

And if you didn’t like anything I just shared with you above, you’d step in to find out ways to do things better and lead with real designs you make and put out into the world.

You’ll have some of the most talented, smart, and funny people all around the world to help you do this work.

If you’re working on a new Basecamp.com landing page and have a question about trends in Basecamp signups, Noah can offer plenty of insights. If you’re curious about what our customers actually want, the entire Support team can give you a top-three list of requests at the drop of a hat. If you think a campaign at Basecamp needs great photography and video to tell your story, our video producer Shaun can be right by your side to film and shoot. We think everyone here is awesome, and we’d love to see you on the Basecamp Team page with us.

About you

You might live in Chicago, and that’s great. But we work remotely, so we’ll give you a fair shake no matter where you live. We want to know that you’ve done this kind of work before. Whether you’re coming from a big tech company or a small mom-and-pop agency, your resume and pedigree don’t matter nearly as much as the real world work you’ve put out in the world.
You may have a copy of Bringhurst’s The Elements of Typographic Style laying next to your copy of Dan Ariely’s Predictably Irrational. You may also have a stack of design, marketing, and advertising books you’re just dying for us to check out, too.
You have a love for writing, an interest in selling, a soft spot for art, and a fascination with technology. We’re hoping you also have completely unrelated hobbies that will make us love you even more.

Ready to apply?

At Basecamp, we have a long standing history of favoring candidates who put in extra effort in their applications. Whether that’s a video of you introducing yourself or making us a custom website—that’s all up to you. We want to know if you’re qualified, a good fit, and most importantly, you want this job and not just any job.
When you’re ready, shoot an email to me at mig_at_basecamp_dot_com with your design portfolio and anything extra you’d like to send along. I’ll share everyone’s applications with the team. When we’ve narrowed down our list of candidates, we’ll reach out to you.
Note: This is primarily a mid to senior-level graphic design position. Applications are due by February 6, 2015. Good luck!
If this sounds like you, I’m encouraging you to apply. If this isn’t you and sounds like someone you know, please pass the word along for us!
Happy Friday!

Design Discussions: Having fun with Basecamp business cards

Mig Reyes
Mig Reyes wrote this on 3 comments

I’m a sucker for “behind the scenes” articles on how other people made design decisions. They’re usually accompanied with neatly packaged lessons for everyone to walk away with.

Designing—especially during the early exploration phases—is anything but neat. There’s plenty of debates, countless iterations, and drive-by critiques.
I’m starting a new series here on Signal v. Noise called “Design Discussions.” Every so often, I’ll take a page out of our company Basecamp account and share the entire discussion behind a design project we’ve done. They’ll be raw and unedited. They might be full of insight, or they might be incredibly boring and expose the weirdness and silliness of each of our coworkers. That’s fine, too!
Either way, I won’t overly explain the reasoning behind what we were doing, nor will I share a top-ten list of things you should try in your own project. You’ll get an uncut backstage pass to the conversations that took our projects from A to B.
So, let’s start with something we had fun with. Around this time last year, we were Becoming Basecamp. With so many employees, it was high time for us to have a new identity, and that included business cards. (Chances for free lunches via fishbowl drawings, as I like to see it.)
If you happen to come across one of us happy Basecampers, be sure to ask for our card. They look like this.

Designing and illustrating the cards took a day. You can see how quickly other folks in the company chimed in to help me try new ideas throughout the day. The full-sized screen capture of the design discussion follows. Click-to-enlarge it to 100% if you’re on a desktop.

Continued…