Get results

In Joel’s now famous (some might say infamous) blog post about hiring, he asserts that you should look for an employee who is smart and gets things done. Let’s stop and think about a variation of that question now. What should a person, as an employee of a company, do to succeed?

I left a comment on Hacker News that basically boiled down to two things:

  1. Get results.
  2. Make sure people know you’re getting results.

…and that’s it. We can sit and philosphize about the ideal startup employee all day (and I’d probably join in!), but at the end of the day, results are all that matter. Let me expand a bit on these points.

I’m sure the vast majority of programmers winced a bit when I said that “results are all that matter”, while the vast majority of evil bosses patted themselves on the back. Let’s face it, everyone has had that boss who told us to “Just forget all that documentation, testing, version control, and process nonsense and just get things done for Christ’s sake. Results matter, not that bullshit!” Let me be clear: I’m not that guy. I’m pro-documentation, pro-testing, pro-version control, pro-process, and pro-other things I’m not thinking about. I support those things because I want to get results. Not that I necessarily do those things as often as I probably should, mind you.

After all, none of those things are an end in themselves. How often does anyone say “The best part of this commit is the documentation!”? But you should still write documentation because it will help you and your coworkers get results later on.

The second point is something I wouldn’t have included at one point in time. After all, results should speak for themselves, shouldn’t they? Sadly, reality doesn’t work that way, and point 2 oftentimes trumps point 1. Perception is reality. You might have built the feature or service that will make it big for your company. But that doesn’t matter if nobody realizes what you built and how great it is.

One issue that has been brought up is that I should add a third point: don’t be an asshole. I must admit that I’m a bit ambivalent on this subject. It’s not that I’m pro-assholes. I’ve dealt with assholes before, and I don’t want to create that kind of work environment. That said, I think that a person is allowed to be an asshole X% more if they’re getting results. We can debate the value of X, but I say that at a minimum it’s non-zero. Especially if it’s in the name of getting more results.

Thus, I don’t think a third point is necessary. You should be kind to your coworkers as long as you can do so while getting results.

So, to wrap this up, I think this makes a pretty good set of criteria to evaluate your actions as an employee of a startup (or any company!). Are you getting results? And do people know about those results?

An engineering primer for designers

So Michael Lopp wrote an incredible piece on how designers’ minds work.  Now as engineers, let’s be honest:  we need designers.  I have yet to meet any engineers who would disagree with this (and aren’t one of those rare designer/engineer geniuses or aren’t incredibly dumb and disconnected from reality).  I know how hard designers have to fight at times to be heard in an organization that is dominated by engineers.  But at the same time, I know how hard engineers have to fight in an organization that is dominated by designers.

I think the most fundamental disconnect is illustrated by this story in Michael’s blog post:

Someone in charge saw the first working prototype of the product and said, “This looks like an engineer threw it together”, (you nod) and “We need a designer to fix this up” (blank stare).

You: “Fix what up?”

Person in charge: “I don’t know… it just needs to… look prettier.”

Designers who have not yet bolted from this article, yet, are now standing on their chairs screaming at the screen as they read this: “I KNOW THAT GUY.”

Yeah, I know him, too. He’s an idiot, but he has good intentions.

I don’t think this engineer is an idiot. But I could see how one might get this impression. The engineer is probably thinking more along the lines of “What’s wrong with it? Could you give me an itemized list of all the things that are wrong with the design? I’ll have them fixed by the end of the week.”

It helps if you understand that the engineer and the Person In Charge (PIC) almost literally aren’t speaking the same language. What the PIC in this case (hopefully) means to say is “You’re more focused on the engineering aspects of this. Let’s bring in someone who’s more experienced with design who can help you do a better job with the design aspects.” The problem is that this isn’t what the engineer is hearing. The engineer is hearing “You have the job title ‘engineer’, therefore you know nothing about design. We need someone who has the job title ‘designer’, because that job title means that they know everything about design. Things will be so nice once we don’t have to worry about you silly people who are labeled ‘engineers’ messing up the design.”

Hopefully, it’s clear to you why this is a bad thing. But because I’m sure there are others out there who aren’t as smart as you, I’m going to spell out why the engineer feels this way, and I’m only going to use one word to do it: meritocracy. You see, we engineers have this grand delusion that an idea should always be accepted based on its merit rather than who came up with it. If an engineer can come up with a good design, who cares? If the designer can come up with a good engineering design, who cares? If the janitor can catch that off-by-one error that’s making the servers crash, more power to him.

I say that this is a grand delusion not because this isn’t a good ideal to shoot for, but because things aren’t that simple. Where this idea breaks down is probably the subject of another blog post, but it probably isn’t relevant anyway. You’re never going to convince the engineers to give up on their grand delusion anyway. The good news is that you don’t need to. You just have to convince them that you have a role in this grand delusion. Here are a few ways you can do this:

Drop the smug attitude, and (politely!) encourage the engineer to do the same. Let’s face it, the biggest problem that engineers and designers run into is one of ego. I, as an engineer, am just as vulnerable to this weakness as anyone else. Pay attention when an engineer starts talking as though they’re the only ones who know anything about good engineering, and you inferior designers know nothing. Your likely first instinct that you should try to bring them down a notch is almost certainly wrong and will probably only make things worse. Rather, you should stroke their ego a bit to get them to listen to you. Try something like this: “You certainly have an engineering prowess that I’ll never be able to have. But every once in a while, I have ideas that make sense from an engineering perspective. Could you at least humor me a bit?” At the same time, try to avoid doing the same thing. Since you don’t really have any control over what the engineer is saying, imagine them saying the same thing as I pointed out above, but with “designer” substituted everywhere you see the word “engineer”.

Make it clear that you’re here to collaborate with them. For every engineer out there that thinks designers exist solely to add unnecessary but pretty fluff to their software, there exists one designer out there who thinks engineers exist solely to translate their designs into software. Engineers are certainly different from designers, but at the end of the day, we’re both human beings with similar needs. We both hate slow software that crashes all the time. We both like software that we can understand how to use. We both want to make software that people will love. We both like working with people who work with us rather than shoehorning us into some role that they’re forced to put up with.

Try to be an “amateur engineer”. The best designers I work with are ones who can pleasantly surprise me with how well they can contribute to the engineering side of the business as well as the design side. Here are a few miscellaneous things you might try doing:

  • Learn to code, especially in Javascript. You don’t have to become an expert. But you should definitely have some knowledge of what engineers go through on a day-to-day basis.
  • Learn to use version control and code review software. Many times, designers don’t realize how much work needs to happen every time they say “Can you make this 1 px taller?” Now, bear in mind that I don’t expect you to enjoy using something like git, nor do I expect you to be an expert at it. That said, I’m floored when a designer checks changes into git instead of expecting me to do all the boring work and making the interesting decisions themselves.
  • Make suggestions. The next time you hear engineers trying to figure out how to solve a problem they’re facing, make a suggestion. Now, realize that your suggestion probably is every bit as silly as you suspect it is. But that doesn’t make it wrong. In fact, you may surprise yourself. Every once in a while, a non-engineer will say “This may be a silly idea, but why don’t we try doing x?”, and it will turn out to be a good suggestion. But even if it isn’t, hopefully the engineers you work with will be willing to explain why your idea won’t work, and you might learn something.

Try to involve engineers in design decisions. Ideally, engineers should be trying to involve themselves in design decisions as in the last point, but you can’t control other peoples’ actions. The next best thing will be for you to encourage engineers to be more involved in design decisions. Sometimes you run into designers whose workflow consists of two steps: 1) Come up with a few designs. 2) Choose the best one based on an A/B test. These people usually forget step 1.5: ask others what they think. Now the fortunate thing here is that you probably can’t get engineers to get involved in every trivial design change even if you tried. But just as engineers may be surprised if you can offer good engineering advice, you may be pleasantly surprised by the design advice engineers get.

All these things will have the effect of making decisions less about who’s the engineer and who’s the designer, and more about what’s best for the project you’re working with them on. And ultimately, I think that’s a good thing. But if you do things right, you can hold on to your ability to be the designer, while gaining the ability to play engineer when need be. The end result is a designer who is a well respected member of a team, rather than a second fiddle to the organization’s engineers or a smug know-it-all that everyone has to put up with.