My first management opportunity came when I was 19 years old, working full time while getting my BS at Syracuse University. I ran an R&D lab staffed by a dozen-or-so students. I’m not sure how I got the position, but I was too young to question whether I deserved it or not. The world was my oyster and my ego was massive.

It wasn’t a total train wreck. In fact we got a lot accomplished, won some awards, got some great press for SU, and all went on to lead successful careers. I’m still in touch with nearly everyone I worked with back in that lab, with the exception of one person. Let’s call him Frank. Frank taught me my first real management lesson, and probably the most important one.

One week, during an all-hands meeting, I asked Frank to present the work he had been tasked with completing the prior week. Frank nonchalantly replied that he didn’t do the work. There were some new team members in the meeting, including Frank, and I didn’t want them thinking this was acceptable behavior. I went on a ten minute rant about how there was no room for apathy or laziness on our team; how it was unprofessional and detrimental to our success. I singled Frank out. I wasn’t yelling, or swearing, or pounding my fist on a table, but I was undoubtedly beating Frank up. I had used this tough-guy management style in the past, and it had always seemed to inspire the team, or at least scare them straight. Yet, in this case, as I was wrapping up my rant, Frank’s face turned bright red, he began to cry, and he stormed out of the room.

Frank never returned. He quit the team and never spoke to me again.

The first lesson I learned that day: beware of calling someone out in a group setting. That’s something that should only be done in the rarest of circumstances. I’ve used that tactic less than five times in my now 15-year management career. When and why to use it is probably worth its own blog post.

The second, and most valuable lesson I learned that day was that everyone is unique. Chances are that the same management strategy that works for one person, won’t work for the next. As a manager, your most important job is to learn how to motivate each employee. Some are motivated by a kick in the ass, others require a gentle pat on the back, others are motivated by recognition of their work, or creative freedom, or financial gain, or job security, or collaboration, or one-on-one communication. The list goes on.

If you can figure out what motivates each and every member of your team, you’ll earn their respect and get the most out of them. That alone won’t make you a great manager, but it’s certainly a good start.

There’s no task more important than hiring good people. But let’s face it, you’re not Google, you don’t have the best and brightest hand-delivering their resumes to your office. You don’t have a massive HR department. You probably don’t even have a single employee with “HR” in their title. You don’t have experienced interviewers who can spend all day quizzing potential hires about the amount of oxygen in the atmosphere, or how people wearing red hats and blue hats can prevent themselves from dying.

So, how does a startup, with limited resources, hire quality people?

Clearly define your needs
Every hire you make must be for a reason. Don’t hire because you’re lonely, or your buddy is looking for a job. Hire because you need to fill a specific void. There’s one exception to this rule, which is when a rock star walks through your doors. At that point, you should change gears and hire for talent. That topic is worthy of a future blog post.

Write up a job posting
It’s important to pick the proper job title.  Don’t make up a title unless that’s part of your company’s culture.  If you’re hiring a “Chief Hacker,” your applicants will expect to be referred to as “Chief Hacker.”   If company politics get in the way and they end up becoming “Senior Programmer,” they’re not going to have a very good first-day.

Beware of gimmicky job titles, they become dated quickly.  Coding Guru and Rails Ninja will attract some and alienate others.  And think about people searching job listings, are they more likely to for “Coding Guru” or “Senior Engineer”? And for the love of god, avoid job titles that won’t make sense to anyone outside of your company.  If nobody knows that your internal CMS is named Bonzo, don’t post a job for “Bonzo Support Engineer.” Yes, that should be obvious, but you’d be surprised how many companies do it.

Start off with a blurb about your company. There’s nothing wrong with writing a dry and conservative blurb, especially if you’re looking for experienced applicants, but try to match the tone to the culture of your company. If you’re a bunch of goofballs, this is no time to be conservative.

Now, what’s this person going to do? If you can’t answer this, refer back to the top of this page. If you’re having trouble wording the roles & responsibilities, search similar job postings on sites like indeed.com or simplyhired for inspiration. Be careful not to use dated buzzwords or incorrect technology terms. The talented applicants will sniff out your ignorance and avoid you like the plague.

Be specific and tough with  your requirements.  It’s miserable sifting through hundreds of entry-level resumes when you’re hiring for a senior-level position.  Don’t worry about alienating people that don’t meet every requirement.  If they have the chutzpah, they’ll still apply.

Positing the job
Start off by positing the position on your own site. Even if you get minimal traffic, it’s worth it for all the bots that crawl your site daily.

Craigslist is always a safe (and cheap) place to start.  Authentic Jobs is worth the cabbage. Dice, Monster, and HotJobs haven’t been useful in years.  I’ve had luck with 37 Signals job board, but no luck with Joel Spolsky’s. One of the best places to find candidates these days is LinkedIn.  It gives you the ability to reach those who aren’t actively looking for jobs.  Those folks are *generally* the talented, passionate, loyal folks. Poach them!

Reviewing resumes
OK, so the job has been posted and the resumes start pouring in. The first few times you go through this process, you’ll likely review each resume from top to bottom. However, after you’ve hired a handful of people, odds are that you’ll start to despise this phase. In order to find that one great resume, it may take reviewing fifty crappy ones. That can be quite a grind.

At this point in my career, I spend seconds reviewing a resume before making a decision. Job seekers, this is why the cover letter resume are so important. To err is human, but there are some documents in business that need to be perfect. When I review a resume, grammar and spelling mistakes are instantly tossed.  Nine times out of ten, that says something about their quality of work.  If the cover-letter is boilerplate garble, it gets tossed.  I want to see someone invest time into researching my company to make sure it’s a good fit for both sides.  Verbose cover-letters get tossed.  Those are the people that end up causing a 15 minute meeting to run 45 minutes.  

Cover letters that say things like “stop your search, you’ve found the right person” get tossed.  Those folks are typically aggressive and don’t work well in teams.  Resumes that aren’t formatted properly, get tossed. I don’t want a text version of your resume with random line breaks and 3,000 word paragraphs.

Resumes with no substance and loads of buzzwords, get tossed. Candidates who spent under a year at multiple jobs, or have inflated titles for their level of experience, raise a red flag.  Folks coming from large consulting companies, applying for startup gigs, usually make me wary.  Those who put their education above their work experience also make me wary. 

Long story short, I’m a prick when it comes to resumes. I didn’t start out like that, but after wasting countless hours on phone screens, I’ve learned that you sometimes, you really have to judge a book by its cover.

(Note to job seekers: Format the filename of your resume as firstname-lastname-resume.pdf. Whoever is reading it, will likely save it to a folder and share it with their colleagues. Saving them the pain of renaming “resume.pdf” will earn you bonus points.)

First contact
After whittling down the pile of resumes to the top 5-10 candidates, it’s time to see how they handle a phone screen. Email each candidate a short message. Something like “Hi John, Thanks for sending along your resume.  Your background looks like a good fit.  Can we set up a time to chat sometime this week?” 

There’s a reason you’ll want to say this, rather than suggesting a specific time. Those who respond with “Sure, I’m flexible, let me know what works for you” get brownie points.  Those who respond with “Sure, does 2:30p tomorrow work for you?” show promise. Those who respond with “Yeah, let’s do that” show a lack of common sense.  Those who respond with “Yes, I can fit you in tomorrow at 2:30″ are usually clueless.

The phone screen
You should initiate the call. Believe it or not, a good number of people will answer the phone like they just woke up.  Bad sign.  And then there are those who you’ll catch completely off guard even though you agreed to chat at that exact time.  BAD sign. 

During the call, let the conversation flow naturally. This isn’t the time to grill them, you really just want to get a sense of their personality and how they communicate. Ask them about their professional background. Listen for passional, self-awareness, confidence, etc. Are they overselling themselves? Underselling?

Ask questions like “what motivates you?” and “describe the ideal job” to see if they’ve actually thought these things through.  Those who can immediately answer those questions, and don’t obviously tailor them to your job opening, get brownie points.  Ask “how would a co-worker describe you?” — that’ll come in handy when checking references.  Ask “what’s the most frustrating thing you have to deal with in your current job?”  If they start venting, it should raise a flag.  Finally, ask “what do  you know about our company?”  If they haven’t done their research, they lose points.

I typically try to cut the candidate off once or twice during the conversation to see if they continue talking or let me interject.  Those who talk over you, tend not to be the collaborative type.

Wrap up the call with giving a little additional background of the company. Give them a feel for the culture, work environment, types of projects they’d be working on, etc. If you like them, this is a good time to start selling your company. It’s not the time to let them know about the skeletons in your company’s closet though. That’ll come later.

What’s next?
Congratulations, you’ve determined your needs, written and posted the job description, and whittled down the list through reviewing the resumes and conducting phone screens. Now, the real interview begins. I’ll cover that in Part II.

Sam has long since migrated to her own room, but I’ve grown accustomed to using my laptop as a TV. I actually find it a more intimate viewing experience. I spend an hour or two every night unwinding in bed (or wrestling with my insomnia), watching DVDs from Netflix. For the last year, I’ve been catching up on all of the television series that I had somehow missed over the years.

My favorite shows have been:

1. The Wire
2. West Wing
3. Sopranos
4. Twin Peaks
5. Lost
6. Rescue Me
7. The Shield
8. Sons of Anarchy
9. It’s Always Sunny In Philadelphia
10. Dexter
11. Mad Men
12. Breaking Bad
13. Californication
14. Band of Brothers
15. Generation Kill
16. Friday Night Lights
17. The Black Donnellys

Update 01/06/11: How could I forget The Black Donnellys?!

And some top-rated shows that I tried, and probably should’ve liked, but didn’t.

1. BSG
2. Deadwood
3. X-Files
4. Alias
5. Six Feet Under
6. Oz
7. Weeds
8. Big Love
9. Arrested Development
10. Rome

The project is a social web application called Kafka. It’ll help web development teams and their customers keep track of frontend changes to their sites. Kind of like an archive.org, built specifically for web geeks.

Upon deploying a frontend change to your site, Kafka will automagically take a snapshot and catalog the URLs that changed.

Seems kinda basic, right? In a way, it is. It’s already quite easy to take a screenshot, and there are plenty of services to manage your photos. Yet, I keep finding myself deep into a project thinking “holy crap, this has come a long way”, yet I have no visual proof of that. As much as I’ve always wanted to, I’ve never paused after each new release to capture the frontend changes.

In these days of release early, release often development, we’re constantly reworking our frontends, adding features, and tweaking the UX. Our sites are evolving faster than ever. Assuming you’re sober, you know how much your site has changed, but do your customers, colleagues, and stakeholders?

We have source control browsers like Warehouse and Github to keep track of the ‘when’ and ‘what’ of backend changes. And we have ticketing systems like Sifter and Lighthouse to document the ‘why’. But these tools are usually too private for your customers and too granular for your stakeholders. Kafka uses simple visuals to tell the story of your site’s evolution to anyone.

You can use it to generate executive reports on the site’s progress, to collect feedback from users as soon as a change is deployed, to show new users how often the site is updated, to start a conversation on your blog, or to fuel your portfolio, etc.

Like the majority of web app ideas, the execution is what will make or break it. It must be dead simple, performing the core task of automatically capturing screenshots with virtually no effort. It needs to display the catalog in a variety of ways, satisfying the needs of each user type. It needs to improve your feedback loop and help manage expectations with your stakeholders.

I’m on it. All of it.

Wish me luck!

For over a decade as a manager / director/ VP, I hadn’t gone longer than a month without at least writing some code. But as soon as I accepted my first CTO job, coding became a thing of the past. It’s as if I had completed the final phase of my metamorphosis from programmer to suit.

My career as a technologist began when I first discovered the web in 1993. I had very little computer experience back then, but was mesmerized by the web and felt an overwhelming need to contribute to it. I taught myself HTML and Photoshop and UNIX and built my first site, “the eye of the storm,” a hideous homepage that utilized every Photoshop filter available.

Soon I became bored with static HTML and spent every waking hour teaching myself Perl/CGI. Like many in those days, I started with a simple contact form, then moved on to dynamic pages, administrative tools, intelligent 404’s, etc. I built my first full-fledged web app, Dr. Iptscrae, in 1995. It was a tool that automated the scripting and configuration of Palace servers. Under the hood, it was a shit storm of cruft Perl – lots of repetition, no commenting, no error handling. Yet was good enough that I sold the code to the folks behind The Palace and walked away with more money than a starving college student knew what to do with.

I never became a rockstar programmer, but over the years, I hacked together more than fifty web apps in Perl, ASP, Java, and PHP. I built web apps for tiny companies, that were used by only a few people and apps for start-ups used by millions of people. I’ve done it as a one-man show, as part of a team, and as a manager. I was that guy who slept in the office and worked from home during vacations, even when my managers begged me to take a break.

But somewhere along the way, building web software became tedious. The excitement of learning and creating was replaced with an assembly line mentality. Every app required the same old methods, business logic, database queries, etc. In hope of recharging my passion, I shifted my focus to process-oriented things like gathering requirements and writing specs. When that became mundane, I moved on to design patterns, code optimization, and hardware tuning. Then I moved on to UX and IA. Finally I moved on to the non-technical realms of launching web applications like marketing and sales.

This is the path that led me to obtain my first executive position — a fantastic opportunity to challenge myself in unfamiliar territory — and use my experience, not my coding, to help guide a new start-up. Nine months after taking the job, I conceived the strategy for, and led my team in the development of a sophisticated social web app. The project lasted nine grueling months, and throughout it all, I didn’t contribute a single line of code.

And to my surprise, I missed it.

I missed being part of those all-night coding sessions. I missed the creative problem solving. I missed being pissed off at the death-march schedule and constant feature creep. After all those years of trying to distance myself from coding, the one thing that finally brought my passion back was, not coding. I found myself with all of this creative energy, and no outlet. I can’t draw, paint, or play an instrument. I’m not a very good writer. I don’t sing or dance. I don’t even like the outdoors very much. As it turns out, I like building software.

I had come up with an idea for a pet project years ago, but was always too fried to build it and was so soured on all of the languages and frameworks that I knew, to use them again on a personal project. I had read a lot about Rails and wanted to learn it, but didn’t have the energy to teach myself yet another framework. I’d been down that road too many times, and while the outcome had always been rewarding, the process could be downright maddening.

And then a couple weeks ago, after a particularly grueling day at work, I woke up at 2AM with a mixture of frustration and creative energy. Instead of fighting it and going back to sleep, I opened up my laptop, and began following a Rails intro tutorial. By 9AM, I had the shell of my new app created. I was coding again! And holy crap, Rails delivered on its promise to make coding fun. Sure, I’ve had some head-banging moments, but in only a couple of weeks, I’m further along than where I’d have been after two months in Java.

I’ve now spent all my free time on the project, which isn’t a lot after a full time job and a four-month old baby. It’s not the next Google — far from it — but it’s something that I’d use as a developer/manager. More importantly, it’s my chance to take everything I’ve learned over the last decade and incorporate it into one (potentially final) web app. I’ll build it myself, design it myself, market it myself, etc. No specs, no mockups, no revenue projections, no meetings to discuss the progress. Just me, my laptop, and a problem I’d like to solve.

Let the experiment begin.