- Brooks’s law: Adding manpower to a late software project makes it later
- Parkinson’s law: Work expands so as to fill the time available for its completion.
- Hofstadter’s law: It always takes longer than you expect, even when you take Hofstadter’s Law into account.
- Clark’s law: Sufficiently advanced cluelessness is indistinguishable from malice.
- Lewin’s equation: B=ƒ(P,E). An individual’s behavior is a function of both their personality and their environment.
- Fast, good or cheap. Pick two.
- “The bearing of a child takes nine months, no matter how many women are assigned.” – Frederick P. Brooks
- Flitting doesn’t work, nor does sitting tight
- Attention economics
- Don’t write a functional spec
- Start-up metrics for pirates
- The Zombie Function: micromanagers create zombies
- Death by risk aversion
- Fail fast, fail cheap (re: tactics, not the overall business).
- Beware of future creep
- To create change, you need to reach out to those who don’t already agree with you.
- The 18 mistakes that kill startups
- 85 operations rules to live by
- Things that get in the way of good software:
- Competing interest (departmental)
- Political infighting
- Lack of audience clarity
- Fuzzy strategy
- No vision for success
- Aspects of good software
- Functionality: does it do what I need?
- Correctness: does it do it correctly, without a bunch of bugs?
- Learnability: can I learn it quickly? Is the manual good?
- Efficiency: does it let me do what I need without long workarounds?
- Usability: is it user-friendly?
- Intuitiveness: does it feel natural?
- Flow/enhancement: does it keep me fully engaged where the world drops away?
What’s your management style? I hear that question often. Truth is, it’s constantly evolving and varies from job-to-job and employee-to-employee.
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.
In real estate, it’s all about the location, location, location. In startups, it’s all about the people, people, people.
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!
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.)
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.
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.
Over the last year and a half, I’ve been using my laptop as a bedroom TV. This started when Samantha was born. When she was sleeping in our room, the light from our TV would keep her up, but my laptop screen wouldn’t. (Noise was never an issue as I’ve always used wireless headphones)
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:
- The Wire
- West Wing
- Twin Peaks
- Rescue Me
- The Shield
- Sons of Anarchy
- It’s Always Sunny In Philadelphia
- Mad Men
- Breaking Bad
- Band of Brothers
- Generation Kill
- Friday Night Lights
- 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.
- Six Feet Under
- Big Love
- Arrested Development
In my last post, I mentioned that I was working on a pet project in Ruby on Rails. While I’m only in the early stages of the project, I’m discussing it with anyone who will listen to help gauge interest and inform the requirements. So, here goes nothing…
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!