GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS

I’ve recently begun a redesign of my portfolio and my biggest blocker is never knowing what to do for a logo or header. Then, last night, it hit me. You don’t need to create anything. Crazy, right? Maybe not for some of you, but for a designer like me, that’s unheard of.

So how do people recognize me?

The answer to this struck me while messing around on twitter, my face is my brand. I recognize people by their twitter avatar. When someone changes their avatar, I have no idea who is tweeting at me. This is incredibly strong branding and most people don’t even realize it. Now just imagine if every place you were, virtually and physically, always had your brand. If you haven’t figured it out yet, you can make this happen. Make your face your brand and you will reinforce whatever you stand for, everywhere you go. More than just your face being your brand, make one particular photo your brand, everywhere. I can’t count the number of times I’ve seen the same people on different sites and recognized them only because they used the same photo. It’s much weaker, and almost pointless, if you change your photo from place to place.

Dan Benjamin wrote a great post on his blog, Hivelogic, about the significance of your avatar, and how never changing it is the only way to go. Smart guy over there!

Trash that old logo

Some people want to use just their name or some forgettable mark. I was a disciple of this belief for the majority of my design career; I used a fedora and my name set in Museo. That’s idiotic. I don’t wear a fedora, and my name is unmemorable. If I’m banking on an employer remembering me they aren’t going to think of the guy that had a fedora as his logo. They’re going to remember my attitude, the interaction between us, and most importantly my face. When they’re thinking of my face, I need it to be easily findable. I want it on the top of my résumé, website, and even my business cards!

Think about these cases

I bet you will recognize a few photos and their subject by a simple description, without even showing you the photo.

• Everyone knows the creator of Myspace, and that photo he never changed. Imagine if Tom changed his photo every week like most of the power social network users do. Tom would be nobody, unrecognizable, and forgotten forever. Now, even though Myspace is a joke, people from our generation will remember Tom and his face for a long time. In my opinion he is still more recognizable than Mark Zuckerberg.
• Remember that blonde bombshell from the 1950s in The Seven Year Itch? Standing above the subway vent, holding her white dress down, as the gust from below blew her dress every which way. Everyone knows that powerful picture of Marilyn Monroe and while she never intended for it to be her brand, it is definitely something she is remembered by.
• How about Steve Jobs? He knows this secret. You’ll always see him in his black turtleneck and thin framed glasses. He actually recreates his single brand image every time he goes out in public. This is the perfect case of branding yourself. It may get boring, but it’s instantly recognizable.

Actually doing it

Like anything else in life, if you’re going to do this, don’t half ass it. Don’t find some weak camera phone picture of you somewhere. Pay, barter, or do whatever you need to get a good photographer to produce at least one good picture of you. thoughtbot hired Jamie Beck, a great photographer we know from New York City. She did an all star job and now we all have super photos to brand ourselves with. You should do the same, and see how much more people begin remembering and recognizing you.

Hoptoad’s growing up!

It’s been over two years since Hoptoad first splashed into our Basecamp project list, and now there are people all over the world reclaiming their inbox and tracking their app errors with us. Here’s a snip from our analytics:

The sun never sets on Atticus’ watch!

To celebrate, we’re offering a new, larger plan: “Bossfrog”

During these two years, we’ve been busy growing as a company, and we know that you have been, too. Congratulations! More and more often, we’re getting support requests asking for larger plans, with more users and more projects.

To support your growth, we’re pleased to offer a new larger plan on Hoptoad: the Bossfrog. We’d like to extend a tip of the hat to our friends at TWG for Atticus’ newest wardrobe addition.

Bossfrog gives you double the projects and double the users, with all the same great Toad taste (and features) of our previously largest plan. As always, you can take it for a spin free for a month. If you really need a lot of the Toad, there is a “Hoptoad behind your firewall” option, where you can run Hoptoad to your heart’s desire in your own data center.

And we measured the Toad.

When I was growing up, there was an area on the kitchen wall that was dotted with small graphite tick marks, and my family members’ names penciled in. My brother and I would often check (and re-check) our height through the years of our youth, arguing over the thickness of our socks and heights of our haircuts, eagerly awaiting the day our tickmarks would surpass those of our parents.

We want to remember and cherish these years in Atticus’ life too, so we’ve taken a few rough measurements to share with you and record for posterity. I’ve also included some reference samples, to help you anchor these numbers against more concrete and familiar things.

We’re pleased as punch to see Hoptoad continue to grow, and are incredibly thankful for you, our customers, who have helped us grow, improve, and shape the direction of Hoptoad. Please continue to let us know how you’re using Hoptoad, what you’d like to see us change, and what we can do to serve you better. Ride the Toad!

Our hiring process has been continually refined over the 7 years we’ve been in business to reflect the needs of our team, the lessons we learned along the way, and the changes in the candidates we see.

In this post I’ll go through our hiring process, note places where we’ve seen changes, and hopefully answer some common questions.

It’s worth noting that we’re currently actively searching for both a new Designer and Developer.  If you’re interested, I hope you’ll get in touch.

The History

When we first started out, we were smaller and we didn’t focus exclusively on Ruby on Rails.  So our decision-making process for hiring new people was necessarily different.

At first, I’d basically talk to people a few times, meet them in person, and make the decision about whether to hire or not largely on my own, with consultation from Jon when he was available or when I thought it was particularly necessary.

Now that we’re a bit larger and have a well qualified team we involve the rest of the team in the decision making process to ensure that the people we’re hiring have been agreed to by the team.

We do this because having a cohesive team is incredibly important to our overall culture and attitude.  We want to make sure that everyone will work well together to uphold our high standards.

Also, because we used to use a variety of different technologies our requirements were in some ways more loose, and in some ways more strict.  For example, we didn’t use Java on every project, but that meant that if you were being hired as a Java programmer you’d be working with particular clients on particular projects.  You needed to be able to perform well on those specific projects as well as just demonstrate a technical aptitude.

Back then, we also didn’t have the standards and practices we do now.  We didn’t write automated tests, we used many different frameworks, and we weren’t as particular about the projects we took or the kinds of people we hired.

When we switched to Rails, that was our chance to push the reset button on our standards, including our hiring process.

We established that we would do test driven development, run continuous integration, more strictly follow agile methodologies and hold ourselves to a higher standard.  Necessarily, our hiring practices needed to change to match this.

The Current Process

We ask all development candidates to provide us with information about them and a code sample as part of the initial contact.

After reviewing the code sample and their resume and cover letter, we decide whether we’ll do an initial interview with them.

We used to only ask for a code sample after the initial interview and before the second, technical interview was already scheduled.  However, after a few candidates who would have never gotten through to the technical interview had we seen their code first got through, we decided to ask for this and evaluate it up front.

The initial interview is either by phone, video chat, or in person based on their capability and location.  This initial conversation isn’t technical at all.  Its a chance for us to hear in their own words what their experience is and for us to give some insight into thoughtbot, how we operate and where we’re going as a company.

If this initial interview goes well, then we’ll ask the candidate to do a technical interview with other members of the team (same for design candidates).

The technical interview is usually with two people, we review the sample code (or designs) ask them questions on that, and also ask a series of more technical questions.

We have some technical questions that we’ve come up with and revised over time.  With these questions we try to judge core technical competency rather than just being up to date on the latest plugin or buzz-word (though those are also things we consider).

For candidates who we think might be a good fit after the technical interview, we then invite them to come and work in our office for a week, for which we pay them for their time.

This week-long trial, particularly for remote candidates, is as much for us as it is for them.  We want to make sure that everyone involved is a good fit before the big decision.

During this week-long trial we try to get them interacting with each member of the team and try to give them as accurate a picture as possible of what its like to work at thoughtbot.

Things We Can Improve

As with any process, this one continues to evolve, and there are certainly areas that we can improve.

We used to do a really terrible job of keeping track of potential candidates throughout the process, particularly in notifying people of a no-hire decision.  We now do a less terrible job by using Wufoo to take submissions in a standardized form and Highrise to keep track of people, but we could stand to do an even better job with this.

As I mentioned above, our technical interview questions try to strike a balance and identify strong core technical competency rather than just being able to spout of the latest buzzwords or familiarity with a specific plugin.  However, our questions could probably try to work with more practical knowledge rather than computer science topics.  We’ve recently made some changes here already, and focus more on the sample code they’ve submitted, but we continue to refine.

Like all things we do, we also don’t want our hiring process to be a burden.  We are a small team with lots of responsibilities.  If anything we do becomes a burden on anyone involved it’s not working.

One problem we were having was that the number of low quality candidates we were receiving took a lot of time to screen.  To help with this problem, we’ve started to avoid posting to job boards right away.  Instead, we’ve focused more on trying to find qualified candidates through networking and directed advertising to more focused groups.  Then, if  we haven’t found someone through those circles, doing a broader search.

Our goal for our hiring process is to find people that will be a good fit with the team and who will do a great job with the kind of work we do.  Our process has been honed over time to hopefully become a useful tool in identifying the right kinds of people for us.

I’d love to hear what you’ve liked or disliked about either side of the hiring table you’ve been on.

The simple fact of the matter is that we care too much about the quality of what we do and the environment in which we do it in.  That’s why, for a few years now, we have not subcontracted for other people and we have not subcontracted out any of our work.

Subcontracting for other people

After a few failures working in a situation where we are subcontracting for somone else we realized that because we didn’t have a direct responsibility to the end customer, and very often no direct lines of communication, we were not able to properly introduce them to our way of working and to properly set expectations.  When we were left to communicate through someone else in order to ask questions, talk about deadlines, etc. there is the danger that it’s not being told like it needs to be told in order to properly set expectations.

In addition, in a subcontracting situation, you are often beholden to a third party for invoicing and collection.  We invoice our clients on a weekly basis, with Net 15 terms.  All too often, when we didn’t have direct access to the end customer we were left waiting for our invoices to be paid while the person we were subcontracting for waited for their client to pay them.

We are in the business of working on successful software projects. We are tenacious about identifying things that aren’t working for us and stopping doing them.  Every once in a while, we identify something like this that becomes a real core principle to the way we work.  These principles, or rules, stand as guidelines to remind us what we need to do in order to ensure success.

Subcontracting out work to others

We also had several instances where subcontracting out work to others didn’t quite work out, and so have stopped doing it.  Everyone who works for thoughtbot is an employee and we don’t subcontract any work out.

One of the main reasons why we don’t do this is that we found it difficult to maintain our high level of expertise and quality when we were subcontracting.  Additionally, we care very much about the environment and comraderie among the team.  In cases where the expertise may have been great, its still hard to integrate that person into the culture of the team, and the contractor is ultimately always an outsider.

I know many firms find themselves subcontracting work that is not their core area of expertise out to other firms so that they aren’t turning away work.  I’d rather turn away work than take projects which aren’t a good fit for us.  If there is a component which isn’t quite right for us, we assist the client in making a relationship directly with someone else to do the work above, for the same reason that we don’t subcontract for people.

Also, working within our core expertise has allowed us to become experts at what we do, which has so many more benefits than the extra revenue we may get by being able to take on and subcontract Flash work.

Breaking the Law

Because these rules are there to guide us, of course there may be situations where we might subcontract for someone or subcontract to someone (there hasn’t been in quite some time) if we try to make the relationship directly with the end customer and subcontracting is the only way we can work, but we think the project might be good anyway.  The rule causes us to remember why we created it in the first place: 1) lack of direct access to the client 2) dependency on a third party for invoicing and collection 3) inability to integrate subcontractor onto the team 4) problem maintaining high level of quality.  If we can subcontract and still work around those key sticking points, then so be it.  However, at least we are then making the active decision. We’ve thought it through and decided that the project can be successful in spite of it, rather than just blindly taking any and every project and praying for success.