The first thing I do when I read an email from one of our customers is to mentally translate what they have written into how I would write that email. I take each sentence, break it down, and rewrite it in my voice, with my understanding of how our software works. Subconsciously, everyone does this to some extent – I’ve found that by making this act of translation a conscious process, it helps me in three ways:

Empathy

This is the most important one for me – by forcing myself to write the question how I would write it, I become the customer. It becomes really easy to share how they feel about the question – whether it is joy or frustration, anger or confusion. Understanding that emotional state helps me to compose an answer that is respectful of how that person is feeling.

Attention to the details

In this email-driven world of ours, we train ourselves to read emails quickly, to skim for the important points in a desperate bid to keep on top of the incoming flood. Speed is good, but it also makes it easy to miss subtle hints that can help you to solve the problem the first time.

By breaking down the email into its component parts so that I can translate each phrase in turn, it forces me to make sure that I haven’t missed anything.

Clarity

When you’ve broken an idea down, and rebuilt it in your own words, you learn how to express that idea clearly. This is helpful in two ways – you can explain the problem to the rest of the team concisely, helping them to identify fixes faster. You can also explain the answer to your customer more naturally. I tend to use the same words that the customer used as much as I can, which cuts down the number of back and forth emails considerably.
These acts of translation really help with customer emails, but the same techniques can help whenever anyone is communicating in their own personal jargon – letters from my accountant and conversations with my three-year-old both benefit from some internal translation. Take the process for a spin – I think you’ll like the results.

The newest member of the operations team.

I’ve spent the last 11 years at a Fortune 50 company, working with a fantastic team of people to build and maintain the brains behind one of the most incredible industrial facilities I’ve ever seen. Despite the efficiency of “the machine,” my work was increasingly complicated by conservative technology and development practices.

37signals stands firmly on the opposite end of the spectrum, with an advanced technology stack bent on squeezing every advantage out of staying current (or being ahead), defining best practices in developing and deploying web apps, and continually identifying trouble spots and taking corrective action.

In 2011, I applied for a position at 37signals because I felt my values matched their displayed values: agility and consistency in operations, and deliberate thoughtfulness in their products. Obviously, I didn’t get the job then. But I kept in touch because I admired the company. And, maybe, just a little, because I hoped to see another position open up.

Last year, I attended RubyHoedown and was fortunate enough to carpool with fellow Louisvillian Ernie Miller. After a long, rambling discussion about Ruby, Rails, and programming – but also about happiness; I decided life’s too short to keep doing things I hate! So in an effort to break out of my rut, I started the Louisville instance of OpenHack. (Openhack was started by fellow Signal Nick!)

When 37signals began looking for a Systems Administrator a couple months ago, I knew I had to dream big and apply – my happiness was at stake! And this time my dream came true.

I’m excited to learn many new things and contribute to the operational success of 37signals. I can’t wait to see what the next 10 years bring!

Hey iOS developers, App Store “screenshots” don’t actually have to be screenshots and they can communicate more than just how your apps looks.

They can communicate:

• Who you are, how hard you worked, and prerequisites to using your app…

  

• Your app’s job…

  

  

• How to use your app…

  

As an aside: keep in mind that these images will be seen outside of the App Store too, such as in Twitter cards…

What’s cool about these screenshots? They’re interesting—i.e. not boring lists! They communicate explicity, often using words. It’s cool seeing the apps from the perspective of being on a phone and in someone’s hand. They use colors outside of the typical app color pallete. They convince me that these apps will do the job. Most important, they convince me that the makers of these apps care.
The apps listed above, and other good examples:

• You Need a Budget (YNAB)
• Vine
• Pocket
• Currency
• Sunrise
• Thinglist
• LinkedIn Contacts
• Tumblr

The 37signals Report Card was launched a few months ago, and this month it brings good news across the board.

Our support team made customers happier faster than ever

With 22,000 emails and 7,000 tweets handled in June, the support team blazed a speedy path, with 93% of emails received during our extended business hours answered within an hour. The average email was replied to in just 6 minutes. Chase recently wrote about how we keep those response times down.
The support team also kept customers happy: 94% said they had a great experience in June.

Our applications got a little faster

A few months ago we decided to replace one of the core pieces of our infrastructure: the firewall and load balancer appliances that all of our applications pass through. As we’ve been working on expanding into a second datacenter, we had the opportunity to try out some new equipment that offers dramatic simplification and performance improvements, and we decided to pull the trigger on rolling them out everywhere.
In mid-May, we switched over to our new F5 BigIP appliances in our primary datacenter in Chicago, and customers started to see the performance benefits we’d seen in our testing. The exact impact varies depending on the application and where you are in the world, but most customers are seeing between a 5% to a 25% improvement in overall page load times (overall, we’re running at about a 12% improvement across all of our customers and applications in the six weeks since we rolled these out). This speedup is especially noticeable when downloading large files.
We’re working on a handful of other projects that we hope will bring further speed improvements to our applications in the coming months.

Basecamp got a load of new features

Basecamp continues to improve. Just this month, we saw:

• A whole new approach to documents, including mobile support and visual tracking of changes.
• A new and clean look to the emails that Basecamp sends out about your projects, todos, and events.
• Improvements to the event history throughout Basecamp. There’s less noise and more useful information throughout comment threads, people pages, and the timeline.
• A ton of bug fixes and upgrades. In all, we deployed Basecamp 207 different times this month.

We’ve got a ton of other great features lining up to launch in the next few months. Stay tuned for future announcements and keep an eye on our performance to see how we’re doing every month.

There’s not much worse than needing help with a product only to be told to wait around until someone can get back to you. That’s why our support team strives to reply as fast as we can when you need that help. We track our average response times each day and work to get them as low as possible.
Today, our average time to first response is 2 minutes. On top of that, 99% of email to our support team are answered within an hour. We’re working on presupport but that might take some time to get right.
So what’s the secret? Like with most things, it’s a combination of things that we do to get that response time as fast as possible.

Make sure you have the right size team.

Jason talks about hiring when it hurts. If your support team is continually behind on answering cases, it’s a world of pain for your customers.
During the New Basecamp launch, people sent in hundreds and hundreds of emails with questions. There were times that we’d still have 400 emails waiting for answers at the end of the day. It hurt us, it hurt our customers, and it simply was not sustainable.
Adding more people to the support team cut that time down. It even gave us a little more breathing room. If someone isn’t at work that day, we’re still okay. We’re at ten people now on the support team, which is the sweet spot for our volume of emails.

Try whole company support.

If you’re a small company watching your payroll, hiring on a new support person can be tough. Instead, have people already on the team do a stint answering support emails. Having a designer or programmer spend some time working with customers helps you get those faster replies. It also lets the rest of the team interact with customers firsthand. It’s a win-win for everyone involved.

Use time zones to your advantage.

Our support team stretches from Berlin to Portland. We’ve got people working on cases in the bulk of our customer’s time zones. That means a Basecamp customer in London gets an answer right away rather than waiting for us to wake up here in Chicago. And by using time zones, we each work typical 9am–6pm hours instead of crazy overnight or weekend shifts.
Back to the New Basecamp launch, Kristin switched over to what we called a swing shift. She’d work 12–8pm to help us be ready for the next day. Staying later in the day made all the difference. It allowed us to reply to customers faster since we didn’t play catch up every morning.
Eventually, she moved to Portland and now stops answering emails at 6pm. All thanks to the power of time zones.

Bottom line – customers don’t like to wait.

I’ve needed help with products before only to find out it’s a 24 hour wait until I would get a reply. That’s insane!
Our customers use our apps to run their businesses. When they’re waiting around, it’s costing them time and money. I’m betting your customers are the same way.
Aim for those fast response times. Your customers will love you for it.

I’m running a conference, NickelCityRuby, in my hometown of Buffalo, NY this fall. I’m no stranger to getting people to code or work together, but organizing an event like this is a new challenge for me. My main goal with the conference has been simply to bring plenty of awesome people to see Buffalo, but another of mine has been to ensure the conference is as diverse as possible. Full disclosure: 37signals is a sponsor of NickelCityRuby.

Diversity is a tough subject in the tech world, and I think it’s something we just can’t ignore. I care about this deeply because I’ve witnessed exclusion happen before (myself being at fault too!), and the only way to make sure it stops is by making conscious decisions to change for the better. There have been several scandals at conferences recently, and this has been my biggest fear of about organizing a conference: Can we deliver a conference that is diverse?

We recently announced our speaker lineup, and I’m really happy with how diverse it turned out. However, I think this is just the beginning of making sure we meet the mark. By no means is being inclusive a checkbox you can just tick off while organizing something: it has to be baked into your decision making process from the start. Here’s a few things we’ve done so far that I think any similar event should think about.

Have a question about one of our products, our technology, how we work, or anything else? Here’s your opportunity to ask.

We’ll be answering your questions live on a Google+ Hangout on Air tomorrow (Thursday, June 27th) from 12:30 to 1:30 p.m. Eastern time.

Check out the event here, where you’ll find the video link tomorrow. You can submit questions via Google Moderator or leave them in the comments here.

We’ll have a range of people from 37signals participating to answer your questions, from designers to support and everyone in between. Almost anything is fair game to ask (we’re a private company, so won’t be divulging any financial information, nor will we spill the beans on future features).

We hope you’ll join us. If you can’t make it tomorrow, keep an eye out for future events!

Ron May, a Chicago tech-community institution, recently passed away. He was 57. Here’s the Chicago Tribune’s obit.

Ron ran The May Report, a long-running, unique commentary on the Chicago tech scene. The best way to get a feel for him is to check out these videos.

He was a reporter, a curmudgeon, a sweet guy, a total pain in the ass. He’d been writing his May Report email newsletter since the late 90s. He rarely missed a tech event, conference, gathering, meetup. That’s commitment.

He’d usually sit in the front row of a talk/event and just interrupt the speaker and ask questions — loudly. He wanted answers and really didn’t give a damn about decorum. No one quite followed up on a non-answer like Ron did.

He loved to get the scoop. He’d record everything with his handheld mini recorder. He’d basically shove it in your face.

A lot of people in the Chicago tech scene would talk shit about him. He was annoying, he was irritating, he’d print things that were supposed to be off-the-record, he’d rarely fact check and often get things completely wrong. Ethics wasn’t his thing. The story was.

But I really liked him. He was an original, a character, a true one-of-a-kind. He’s covered me… awkwardly... over the years — even calling me a socialist (which is hilarious) — but that was always fine by me. It was so refreshing to see someone truly interested in the scene and subjects he was covering. The May Report wasn’t just a job to him. He was really into it. He wanted to be doing this and he did it like no one else could.

This guy was curious. To me, curiosity is his legacy. And what a great legacy for anyone to have.

Ron will be missed. He even scooped his own death in his heartfelt and honest final May Report, published on June 24th. How’s that for doing what you love right up to the end? We should all be so lucky.