Development resources are in high demand. As more venture capital pours into startup companies, it is becoming harder and harder, for small and big companies alike, to find good development talent. Development costs go up, loyalty goes down and companies spend more time recruiting and interviewing, thereby diverting from their core focus. Recently, a lot of people have been asking for my advice on how to deal with this growing challenge.
The bottom line is that it is hard to find good engineers. There are a lot of people out there who can “write code”, but very few good engineers. Here’s the good news — you only really need a few really good engineers. Beyond your initial core team, in my experience, you’ll see diminishing returns as your development team expands. Further, your core group of really good engineers will set the tone and example for everyone else and will likely always represent 80% of the value delivered by your development team.
My next five posts will be focused on 5 tips that I put together for dealing with the tech resource challenge:
1. Scrappy versus Steady
2. Under Process, Over Deliver
3. Virtual Location, Location, Location
4. Build a SWAT team
5. Outsourcing
1. Scrappy versus Steady
(Part 1 of a 5 part series: “So, you need to develop a product?”)
During the beginning stages of development, I personally think the most important thing is to have a small team of “Scrappy” developers. Scrappy developers move fast and have the agility needed to accommodate quickly changing product requirements. Personally, I think the best products are designed, architected and built all at the same time. (As opposed to the traditional methods of spec’ing out a product in advance with well-defined documentation and then handing that off to a development team.)
As your company, development team and product grow, the process will likely need to become more formal. That’s when you’ll need to introduce “Steady” engineers to add some balance. Steady engineers tend to move slower, but at a more consistent pace, and are more focused on quality.
Scrappy engineers have great vision, they tend to be their own product managers and they do a great job creating very appealing, innovative products. However, they are easily distracted, become unfocused and very rarely document anything (can become a problem if you lose them or as you grow your development team). Scrappy engineers may also be more likely to sacrifice quality for innovation.
Steady engineers bring focus, quality and process. However, they often times are more impressed with the methods than the results. They will slow down the development cycle and you’ll get less features, less often, but the product will be of higher quality. Steady engineers are likely to sacrifice innovation for quality.
Bringing in Steady engineers too early could result in a less competitive product, bringing them in too late could result in instability.
Personally, in the beginning stages (pre-version 1 through v2), I like to have 100% of my team comprised of Scrappy engineers. As the product reaches maturity, I like to have a balance of 70% Scrappy and 30% Steady. Scrappy engineers are harder to find and keep motivated than Steady engineers, so achieving this ratio is definitely a challenge.
How do you identify a Scrappy engineer? Well, first and foremost, it is not by their resume. Their resumes likely show them bouncing around from job to job and they probably aren’t very well-written. Some of my best engineers have had the worst resumes (or sometimes no resume at all). I’ve hired some of my best people straight out of college, taxi cab drivers and have even stolen coffee makers from Starbucks. Some of these people grew to be my most talented and influential engineers. (Yes, I did say taxi-driver and Starbucks coffee maker, and yes, those are real stories. I found them by noticing the books that they had around for reading during their downtime at work; books on C++, Perl, PHP, etc.) I found my Scrappy engineers by judging them on passion, pride, creative personality and most importantly those who had an extreme desire to learn. Experience was one of the last things on my list.
Whether it be a search engine (like Starting Point, Startup 1.0) or an enterprise software product (like StrongMail, Startup 5.0), I have always employed this principle and it has never failed me.
Some have argued that my Scrappy principle only works for small, startup companies. I’ve personally seen big companies such as Ticketmaster and MySpace do a great job building an extremely talented team of highly motivated, Scrappy engineers. I asked the President and COO of Ticketmaster (formerly CTO) how he is able to attract and keep such a Scrappy, motivated team at such a large company. He simply said that he makes sure that they always have “interesting problems to solve.”
So, find Scrappy engineers, hire them, motivate them, keep them happy and keep them challenged. They will be one of your most valuable assets.
Next… Under Process, Over Deliver (Part 2 of a 5 part series: “So, you need to develop a product?”)
