Raising money for revolutionary startup ideas

Posted on September 22, 2012 by Simeon Simeonov

Between the work we do at Swoop and some big idea startups I’m advising, revolutionary innovation has been top of mind for me recently. That is why the following statement Richard Feynman makes in a lecture about the difficulty of understanding quantum mechanics stuck a deep chord:

So, it will be difficult but the difficulty really is psychological and exists in the perpetual torment that results from you saying to yourself “but how can it be like that” which really is a reflection of an uncontrolled–but I say utterly vain–desire to see it [quantum mechanics] in terms of some analogy with something familiar. I will not describe it in terms of an analogy with something familiar. I will simply describe it.
— Richard Feynman

Revolutionary innovation often faces substantially bigger challenges than evolutionary innovation not because of the magnitude of change it requires in a real sense but because of the magnitude of psychological change required to accept the possibility of a new reality before it has fully manifested itself.  Startups building revolutionary new products and services face the additional challenge of having to convince investors about the possibility of a new reality before they can set out to create it. The typical approach is to draw on analogies to existing solutions, to the current reality. Compare. Contrast. Educate. This sometimes works but, in my experience, it often confuses investors more than enlightens them. Explaining the future in terms of the past works well for small evolutionary steps but if often fails for big discontinuous leaps. What analogy can you draw between a sailboat and steam ship? Between a propeller and a paddlewheel? A hot air balloon and an airplane? A feature phone and the iPhone?

Rather than highlighting the potential of the future, analogies to the past constrain it. Worse, in the minds of investors, these comparisons can set up the wrong benchmarks to evaluate a startup’s progress by, which can hurt the company in later financings. Sometimes, the best strategy is to just tell it like it is and only engage deeply with investors who “get it”, who are willing to suspend their disbelief and imagine a world where the revolutionary innovation has reached critical scale.

Here is Feynman. The quote is at 7:10.

Posted in startups, Swoop, VC, Venture Capital | Tagged , , , | 14 Comments

Startup Weekend Rocks

Posted on April 28, 2012 by Simeon Simeonov

Startup Weekend has become a real force for fostering entrepreneurship. I had the pleasure of speaking at the BostonEDU Startup Weekend kick-off yesterday. Some of the ideas were impressive and I do expect to see a couple of interesting companies come out of the event. I also met some really strong developers. If their startups don’t get off the ground, I hope they consider joining me at Swoop.

Here are my slides and the crib notes:

  1. Do not be cool. Entrepreneurship is about action. Most startup ideas never get acted upon. Let your emotions give you energy to overcome the inertia to act.
  2. Practice educated ignorance. To solve big problems in new ways you need to be reality-based but you also need distance & perspective. Find a balance and avoid what at TechStars we call mentor whiplash.
  3. Bring a gun to the knife fight. Startup Weekend may be about a lot of things–building community, collaborating, coming up with good ideas & starting companies to name a few–but at it’s core it is about selling. You need to sell yourself and your idea so that you can recruit a great team at the event and accomplish seemingly impossible things over a single weekend.
  4. Beware the Kool-Aid. Not the proverbial Kool-Aid, the banal one. Startup Weekend is an athletic event: 54 hours of excitement and stress. If you want to perform at your best, you have to take care of your body: eat well & stay hydrated.

If your startup gets off the ground, you may find the following helpful:

Posted in startups | Tagged , , , , , | Leave a comment

Solve hard problems and fly robots

Posted on October 5, 2011 by Simeon Simeonov

Because we are in stealth mode, people regularly ask me what we do at Shopximity. Stuck between changing the topic and saying that we make shopping better for everyone, I decided to take a different tack and tell the cold, hard truth:

There it is. There is no more. For now. Except that we are looking for a someone special.

Front-end Engineer (UI/UX)

Shopximity, an early-stage startup, is looking for a front-end engineer. You’ll work with industry-leading Bocoup engineers and an experienced team of startup veterans at Shopximity to develop a system that will improve the user experience of 100 million people daily. As the first front-end engineer, you’ll both define and solve the many interesting problems we face as we develop the product from scratch.

In case you are not the right person but know someone who is, we offer a $10K referral bonus. Try us. Tell us about your worst competitor’s best engineers and we’ll hire them away and send you $10K.

Requirements and qualifications:

  • Thorough experience with JavaScript, HTML, and CSS (we use JQuery).
  • Thoughtful interaction design and sensitivity to user experience.
  • Experience working with high-traffic websites (>500k monthly uniques).
  • Entrepreneurial approach to your work. We don’t want to manage you, we want to enable you to make the product better and its users happier.

Things we’ll like about you:

  • You are a problem solver and you like gnarly problems.
  • You care deeply about user experience and empowering users.
  • You’ve worked at, or are very interested in, consumer web startups.
  • You’re always thinking about ways to make your favorite websites better.
  • You’re interested in the mobile web, too, and have some ideas about designing for smaller screens.
  • You’ve worked with a backend framework like Rails (which we use), Django, etc.
  • You’re not afraid to voice your opinion and argue for it, but want to arrive at the right decision after thoughtful debate about what’s right for the product and its users.

Things you’ll like about us:

  • You’ll work with, and learn from, people who have built many startups before, taken them public and won TechCrunch 50 awards. Think a startup bootcamp but faster paced.
  • We have a mission. It is to make shopping better for everyone on Web and mobile.
  • We use a cutting-edge stack in the cloud that will handle many billions of requests.
  • We’re well-funded and backed by some of the best investors from the East and West coasts. Well-known people in our industry have joined as advisors to help us in our mission.
  • We take care of our engineers. We have a bright office next to the Alewife T Station. Every workstation has two top-of-the-line monitors and an adjustable-height desk.
  • Generous compensation, including ground-floor stock options. We want to hire the best and treat them like the best.
  • We’re very early stage (5 people) and you can make a meaningful difference immediately because we run weekly sprints.

Please send your resume as well as links to your portfolio, GitHub or Dribbble. Include links to professional or community projects you’ve worked on. Additionally, please tell us a few sites whose UI/UX you admire, and tell us why.

Posted in Shopximity | Tagged , , , , , | 2 Comments

Marketing Secrets of Successful Startups

Posted on September 14, 2011 by Simeon Simeonov

I am thrilled about the speaker line-up for the FutureM Marketing Secrets of Successful Startups event sponsored by Shopximity. It’s tomorrow, Thu 9/15/2011, 11:30 – 1:30pm at CSN (177 Huntington Ave in Boston, 24th floor). Hope to see you there!

[Tweet to tell your followers to come!]

You’ll hear from the following top marketers and entrepreneurs:

  • Adam Berrey, Free Agent. Adam has spent that last 17 years working in technology marketing covering the full spectrum from strategic marketing through marketing communications at companies such as Allaire, Macromedia and Brightcove.
  • Chris Hulls, the founder & CEO of Life360, is at the forefront of rethinking mobile marketing through the lens of value-added service integrations.
  • Chris Savage, Founder & CEO, Wistia, a startup he co-founded a year after graduating from Brown University with a degree in filmmaking. Chris was named a Best Young Entrepreneur by BusinessWeek in 2009. Chris helped produce and bring to theaters an Emmy award winning film, “Buddy.”
  • Christopher O’Donnell, director of product management at Hubspot, the inbound marketing company, where he arrived via the Performable acquisition. Christopher is a mentor to many and a well-known expert on performance-driven design. He likes making something amazing out of nothing.
  • Dave Balter, Founder & CEO, BzzAgent (Dunn Humby). A co-founder and current executive council member of The Word of Mouth Marketing Association, Dave is an international speaker on the topic of word-of-mouth marketing. Dave built and sold two promotional agencies prior to forming BzzAgent.
  • Sarah Hodges, Director of Community Marketing, Runkeeper. Sarah is a well-known digital marketer and blogger who practices a data-driven approach to marketing. She is an expert in viral marketing using emerging channels.
  • Sim Simeonov, founder & CTO of Shopximity and a board member of MITX, the organizer of FutureM. He invests in and advises startups through FastIgnite and is a TechStars mentor. Sim has been a founder, CXO, investor and board member at more than a dozen startups. He likes big successes and small failures.
  • Stephanie Shore, VP of Marketing, ZipCar. Stephanie is a marketer with deep intuition about both content and people. She is an expert at helping people express themselves within the context of a brand experience. Before ZipCar, Stephanie helped people make sense of the world around them through boston.com.

The hashtags for this event are #FutureM and #MSSS. Please, thank my co-host Christopher O’Donnell, our sponsor @shopximity, @wayfair (CSN) for hosting us in their great space and @FutureMBoston & @MITX for making it all possible.

Posted in Digital Media, startups | Tagged , , | Leave a comment

Mobile Marketing Frontiers

Posted on September 13, 2011 by Simeon Simeonov

I am thrilled about the speaker line-up for the FutureM Mobile Marketing Frontiers event Shopximity has organized. It’s tomorrow, Wed 9/14/2011, 8am – noon at Microsoft’s NERD center (One Memorial Drive in Cambridge). For more info, check out the event description. Hope to see you there!

[Tweet to tell your followers to come!]

8:00      Opening remarks

Simeon Simeonov, Founder & CTO, Shopximity
@simeons | @shopximity

8:15      Keynote

Robert Tercek, General Creativity & This Week in Social Media
@superplex

9:00      Demos

Chris Grayson, Director of Digital, Humble
@chrisgrayson | @humbletv

Chris Hulls, Founder & CEO, Life360
@chrishulls | @life360

Seth Priebatsch, Founder & CEO, LevelUp
@sethpriebatsch | @thelevelup

Thi Wernau, VP Business Development, Skyrockit
@thilinh | @skyrockitsf

10:00    Fireside chat & audience Q&A

10:30    Networking break

11:00    Executive panel

Lars Albright, Founder & CEO, SessionM
@sessionm

Ron Elwell, Founder & CEO, Shopximity
@ronelwell | @shopximity

Scott Meyer, Founder & CEO, Evidon
@scottmeyer | @evidon

The wireless guest code for the Microsoft space is fm912.

The hashtags for this event are #FutureM and #MMF. To follow all the speakers & companies at the event and more, check out my Mobile Frontiers Twitter list.

Please, thank our sponsors @shopximity & @gcvp, Microsoft for hosting us in their great space and @FutureMBoston & @MITX for making it all possible.

Join us tomorrow (Thursday, 9/15/2011) at Marketing Secrets of Successful Startups: 11:30-1:30pm at CSN (177 Huntington Ave in Boston). Hear from marketing gurus who have grown ZipCar, Hubspot, BzzAgent, Wistia, RunKeeper & more.

Posted in Digital Media, Mobile, Shopximity | Tagged , , , , , | Leave a comment

One line Tropo debugging gem

Posted on August 4, 2011 by Simeon Simeonov

I’ve worked with Tropo, a cloud telephony platform, for a few months now, primarily using the Ruby scripting API. Tropo’s script execution model is a bit strange–the script file is pre-pended with a bootstrap block of code and the combined stream is executed inside a JVM (so it’s JRuby, really). Stack traces in logs report line numbers from that composite file, which don’t map to line numbers in the the source script–they are offset by the bootstrap code block’s length. My most useful Tropo scripting debugging aid is the first line of my Tropo scripts:

$currentCall.log "---- Tropo first line offset is #{__LINE__}"

This is how I know to subtract 215 from the line numbers to map to my code.

Posted in Code | Tagged , | 1 Comment

How to set up reference checks

Posted on May 3, 2011 by Simeon Simeonov

Swoop (what used to be Shopximity) is in full-on recruiting mode. We are looking for both experienced and up-and-coming full stack developers who love startup life, open-source tools, cloud deployment and are deeply plugged into the tech ecosystem. I’m having a blast meeting with great engineers.

The part that is proving less fun is setting up references–it just takes too long to schedule them and it slows the entire recruiting process down. In fact, a back-channel reference currently takes me about 3-4x less time to get to than one a candidate provides.

The typical process for setting up a reference check goes like this:

  1. Hiring manager asks for references
  2. Candidate sends emails to several people asking for a phone call
  3. Scheduling back and forth
  4. Candidate talks to reference about opportunity
  5. Candidate shoots an email intro to reference and hiring manager
  6. Scheduling back and forth
  7. Hiring manager talks to the reference

The process takes too long because scheduling happens twice, serially. A better, faster way to make things happen is for the candidate to send an introductory email along the lines of the following:

Joe, Sim (http://linkedin.com/in/simeons) is recruiting me to [the ground floor team at his new startup] Swoop. I’m interested in the company because they are solving some very hard problems at the intersection of search, content & advertising–areas that I have a lot of interest in. I’d appreciate it if you took some time to give him a sense of what it’s like to work with me and what I bring to a venture. You can reach Sim at xxx-xxx-xxxx.

Sim, Joe (http://linkedin.com/in/wiredbrainjoe) was CTO at WiredBrain back when we were working on the mobile SDK for brain implant location tracking. He recruited me to WiredBrain in 2005 and was my boss until 2008 when I left to join Google. You can reach Joe at xxx-xxx-xxxx.

Best regards,
Candidate

Here are the top three reasons why this works so much better:

  1. The candidate comes off as more confident because they are ready to make a direct connection with a reference. The process moves faster. A decision is reached sooner.
  2. Candidates save time because they are out of the scheduling loop. If a candidate wants to talk to the reference first, he can send a separate email to the reference and not include phone numbers. Otherwise, adding phone numbers helps because sometimes one can squeeze a lot more calls in a dedicated block of time as opposed to having to schedule every single call.
  3. The email provides context that’s helpful to everyone and makes reference checking more efficient. There is information about the two people who are about to talk. There is some information about the company and the candidate’s interest which can be helpful to the reference. There is also information about the context of the relationship between the candidate and the reference and the type of work that was done which helps a hiring manager set up an efficient reference check.

Last but not least, don’t set up just a couple of references. Set up lots. The hiring manager doesn’t want to and probably won’t talk to all of them but they’ll be able to get through a handful quicker and reach a decision sooner. It also shows a lot of confidence to set up many references. If you only set up a couple, there is always the question of whether these are the only people who know you and your work.

Posted in startups | Tagged , , , | 4 Comments

Shopximity wants to give you $10,000

Posted on April 11, 2011 by Simeon Simeonov

I was prompted by a comment on a recent blog post about recruiting top engineers to formalize a simple suggestion I’ve made to startups over the years: if you have the money to use recruiters, offer a $10K referral bonus to anyone who helps you make a hire. That’s what we are doing at Shopximity.

The reason is simple. If a company is willing to pay $20+K to a recruiter for a great hire, why shouldn’t it be willing to split that bounty with someone else who gives them a great lead? It’s less about the actual dollars and more about the fairness of it. I’ve had people tell me they wouldn’t take the money. That’s cool. I can make a donation on their behalf or give it to a startup organization or a movement such as #RubyRiot.

The rules are simple:

  1. No spamming. Any referral must come with clear reasons why you think the person would be great at a ground-floor startup. Please, respect our time.
  2. Whoever refers a person first wins unless the quality of referral varies substantially, e.g., just mentioning someone you don’t know vs. mentioning a friend and offering an introduction. Within reason, the later but stronger referral would win.
  3. The usual recruiting fee restrictions apply.
  4. Yes, you can refer yourself.

Because of the strength of our founding team and our investors, we are going after some wonderfully tough problems. Here are the types of talent we are looking for:

  • From a culture standpoint, we want curious, high-energy, hands-on, know how to ship, agile everything engineers who take pride in their work and in making customers happy. People who see technology as a tool, not an end. These are the kind of people who know that a problem must be fixed twice: the first time to make it go away and the second time to make sure this type of problem never reaches production again. The best of them know how to have fun after work.
  • From a platform standpoint, we touch iOS, Android, Web and mobile Web (HTML5 + AJAX), Java + Python and/or Ruby. Hadoop and NoSQL work is guaranteed as is cloud deployment.
  • From a development process standpoint, we aim to be extremely agile with short iterations and very small integration batch sizes (continuous integration for sure with the goal of continuous deployment). This makes for the most satisfying, high-velocity environment to write code in.
  • From an experience standpoint, we are looking for both experienced senior/architect-level engineers who have “done it before” and rockstar junior engineers that can do it because they don’t know it couldn’t be done.
  • We are good mentors–check us out. It really matters to us that the people on our team have fun while developing in their careers so that they can do whatever they want (get promoted, start a company) next time around.

Here are some tips:

  • You don’t need to send a resume or get someone interested in working with Shopximity before referring them. Sometimes, the best thing to do is simply to identify someone truly great and let us take it from there. Shopximity is doing some pretty amazing things and so far everyone we’ve reached out to has been interested in being considered for our team.
  • Don’t worry about specific job titles–those are fairy flexible based on the candidates’ career goals and experience. Just point us to great people.
  • Mess with your competition: if your competitor has some great people on their team, tell us and we’ll recruit them away.

Let’s get going. Follow me @simeons and send me an email at sim at shopximity dot com if you have someone for us.

Posted in Shopximity | Tagged , , , , | Leave a comment

Getting developer interviewing right

Posted on March 30, 2011 by Simeon Simeonov

Much buzz today on HN about developer hiring with Evan Carmi sharing his Google interview experience, which mostly consisted of language trivia and algorithmic tasks, and a devininterviews follow up arguing that this interviewing style leads to bad hires.

I don’t think there is one right developer interviewing technique. It is worth mastering a variety of interviewing techniques and then adjusting based on the job requirements, team composition, manager style and company culture.

Here is an initial (incomplete) list. I’ll update with new content from comments & conversations.

Programming language questions

Examples: what’s the order of C++ class data member initialization, how is the value of self determined in a Ruby block and what’s the difference between class and function decorators in Python.

Why: I want to know whether you know the tools of your trade.

Good for: quickly checking the box on language proficiency.

Useless for: determining whether you can code well in the language. I know developers who write kick-ass, elegant code using 50% of a modern language’s features. That’s awesome.

On-the-spot coding of algorithmic problems

Examples: write a binary search, write a Sudoku solution checker and write a substring search.

Why: I want to know which developer group you belong to: the folks who can solve algorithmic problems or the ones who could churn dozens of MVC screens but couldn’t build a fuzzy string matcher to save their lives, even with resources online.

Good for: vetting analytic thinking and coding precision under pressure as well as basic verbal communication & organization of thought. Bonus: easy way to see how you handle criticism.

Useless for: understanding how you’ll write practical code and handle criticism on a team. In the real world engineers solve problems not in front of a white board but at their desk, with Google, GitHub, their co-workers, hacker buddies, Twitter friends and the Stack Overflow community. If your development velocity is great, I most likely won’t care whether you do it by memorizing the algorithms textbook or submiting a dozen questions per week on Stack Overflow.

On-the-spot debugging

Examples: find the bugs in this listing or I have this project loaded in Eclipse and this bug ticket here — go at it.

Why: just as I want to understand your development workflow, I want to understand your debugging workflow.

Good for: getting a sense of how you wrap your head around other people’s code.

Useless for: being sure that’s how you’ll debug normally.

Take home programming tasks

Example: Here are two empty git repos. By 10am PT tomorrow build and deploy two applications on Heroku. The first exposes a REST API for logging session events with arbitrary JSON-based parameters and saves the events in an SQS queue. The second pulls events from SQS and saves them in a MongoDB database hosted on MongoHQ. You can use whatever gems you want.

Why: I want to get a sense of how you work in the real world. I want to look at the code you write but I care even more about what you consider “shippable”. Here are a few things I’d pay close attention to beyond the obvious code style/quality that you may not even know you’ll be evaluated on:

  • How did you deal with fuzzy requirements?
  • What was your git workflow: commit frequency/atomicity, batch size, branching strategies. How you use source control alone is a great indicator of how you’ll use source control on a team.
  • Did you choose Rails or Sinatra? Why?
  • Which AWS gems did you pick? Why? How did you evaluate the quality & fitness of a gem?
  • Did you use TDD? I don’t mean did you deliver tests in the end. I’m interested in whether the tests hit the repository no later than the features.
  • How extensive is your testing? Do you have integration tests? Acceptance tests? Did you set up dev & staging SQS queues?
  • Did you think about securing the REST API? How?
  • How do you manage sensitive info? Is your Amazon secret in the git repo or does it get set as an environment variable? What about the MongoHQ credentials? What about sanitizing the logs?
  • How paranoid are you about failure? Did you pop() from SQS assuming a MongoDB write will succeed or did you peek() and only delete from SQS when you know the message contents made it into Mongo?
  • Are you checking for duplicates in Mongo?
  • How did you set up Heroku? Do you have staging apps as well as production apps? Did you set up deploy notification hooks? How about monitoring for the apps?
  • Did you think about scaling? Did you write any code for it? Did you do any load testing? When does your current deployment break?
  • Did you write any docs? Do you know your audience?

Good for: a litmus test of your ability to build, ship, operate and communicate. Getting a “fingerprint” for how you work.

Useless for: deeply understanding how productive you can be on a team. There is no teamwork component here and it’s hard to separate the various elements that contribute to the final product: your prior knowledge and experience, help you get from a buddy or online resources, luck. Plus, to really evaluate your performance will take a lot of work.

Take-home debugging

Examples: (actual problem I used to give) here is a simple linked list implementation in C++. Find the bugs.

Why: just as I want to understand your development workflow, I want to understand your debugging workflow. Some of the bugs are subtle. I hope you talk to friends about the problem.

Good for: getting a sense of how you wrap your head around other people’s code and how you work with others to solve problems.

Useless for: determining how much of the outcome was “pure you” vs. “you + others”

High-level questioning

Examples: from devin interviews:

  • What’s the last project you worked on at your former employer?
  • Tell me about some of your favorite projects.
  • What projects are you working on in your spare time?
  • What online hacker communities do you participate in?
  • Tell me about some (programming/technical) issues that you feel passionately about.

Why: I want to get a sense of who you are as a developer and how you might work on a team.

Good for: knowing who to reject quickly and who might be a good cultural fit.

Useless for: deeply understanding who to say yes to. Bottom line: great interviewees can prep for and ace this because it’s too general.

Behavioral interviewing

Examples: tell me about a situation where you had to deal with a bug that only appeared under load in production + lots of specific follow-on questions

Why: two reasons: (1) other things being equal, past performance in similar situations is the best predictor of future success and (2)  behavioral interviewing gets down into the nitty-gritty and breaks through BS effectively.

Good for: drilling into specific areas of interest

Useless for: covering a lot of ground quickly and useless if the interviewer is not experienced in the technique and does not apply it in a disciplined manner.

I know I’ve missed many techniques and the “high-level questions” group should be broken into several. I’d welcome ideas on how to do it.

 

 

Posted in startups | Tagged , , | 12 Comments

The three rules of awesome mobile hackers

Posted on March 28, 2011 by Simeon Simeonov

One of the reasons why I’ve been mostly absent from this blog is that, together with a couple of very interesting people, I started a new company and we’ve been busy closing our Series A and getting things off the ground. More on this in another post.

This post is about mobile developers or, most precisely, about talent development in the mobile ecosystem. In the past few weeks I’ve been recruiting, I’ve learned a few things about the current state of the iPhone/Android developer ecosystem that I’d like to get your thoughts on.

My new startup is at the intersection of mobile, local, retail and advertising. We are taking a contrarian approach in this bubbly space born out of deep customer relationships. Because of this customer connection, contrary to many others in the space, we have a pretty good idea of what needs building. It’s one of those “they asked us to build it and are waiting with their checkbooks open” types of situations. This doesn’t say much but it sets up the problem.

For us, user experience matters a lot but distribution matters even more. Distribution is why we are not going to build the 113th mobile-local-retail-advertising app. There are plenty of apps that touch the lives of shoppers. Rather than competing with them, we want to help them create a better user experience and make more money, in that order.

No, we are not an ad network. The above two goals are impossibly at odds with one another when an ad network is involved. Giving the bottom portion of an app’s precious screen real estate may make the app developer some money but certainly doesn’t improve user experience. We are doing something that’s never been done before on the client side that, if we solve some very challenging problems in an elegant manner, can both generate substantial revenues for app developers and lead to a stickier and more engaging user experience.

Technically speaking, we’ll integrate with apps both through existing services they use as well as our own SDK. We need to do some serious jiu-jitsu in order to make app developers’ lives easy. There is low-level device/framework work. There is also fancy GUI work. It’s stuff that’s never been done before on a smartphone. It’s the kind of thing that can improve the user experience of tens of millions of people. It’s the kind of thing I need awesome mobile hackers for, starting with the iPhone and Android platforms.

Here are the three core rules that, for me, define awesome mobile hackers:

  • They have done low-level mobile development. They don’t have to have worked on a mobile OS but they know and have rearranged the innards of mobile frameworks (or their desktop counterparts) such as Cocoa (Touch) on the iPhone and understand what it takes to do fast, efficient and reliable communication with servers. They have a thorough system-level understanding of how the device, the mobile OS, the high-level framework and the app coexist. This allows them, with hardly a thought, to power through the types of problems others post of Stack Overflow.
  • They deeply understand end-to-end mobile app development and lifecycle and have built a number of mobile applications. This allows them to relate to and empathize with the experience of other mobile app developers. That’s why awesome mobile hackers build tech other developers find sexy.
  • They are active in the ecosystem. They have lots of friends doing cool work. They know people on the iOS and Android teams at Apple and Google who will more often than not enjoy going out to lunch with them at a conference. They pay it forward. They contribute to open-source projects and mentor up-and-comers. This builds good karma, which invariably helps them out with life on the bleeding edge.

In the past few weeks I’ve come to believe that the iPhone and Android ecosystems are evolving in a way that fundamentally works against the development of awesome mobile hackers. This very much reminds me of the mid 90s when, as the chief architect of the first Web application server, I watched the explosion of the Web developer community. For a more recent reference, what I’m seeing in mobile from a talent standpoint is worse than the bubble in Ruby-on-Rails development. Here is why:

  • There is too much money to be made in consulting. Apps are churned out on a conveyor belt. The focus is on speed and reuse so why bother learning hard things such as low-level mobile development? Non-visible features pay less because clients don’t appreciate them as much. On top of this, mobile devices are locked down to an extent, which limits the practical value of low-level mobile work. Few try it and why even fewer become great at it.
  • On the flip side, many low-level mobile developers come from mobile OS backgrounds and, unfortunately, don’t like to build apps. Even when they do GUI work they tend to find it “below them.” This makes them blind to the perspective of app developers. Those are the guys that build wonderfully-architected frameworks that nobody wants to use.
  • In this crazy environment of excess demand, developers get very, very busy and spend much less time connecting with their peers, contributing to open-source projects, etc. Skill development becomes almost entirely job-driven as opposed to personal interest-driven. Foundation skill development doesn’t pay and is therefore deemphasized.
  • Conveyor-belt consultants, as opposed to long-term independent contractors or outsourcers, tend to lack appreciation of the ongoing lifecycle of an application post ship. Enough said.
  • The awesome mobile hackers employed by larger shops are used as fire-fighters across many projects. They gain breadth and exposure but lose depth. They also lose the motivation and satisfaction of owning the building and shipping of products. This numbs the soul of a developer and is a topic many top geeks at consulting companies have discussed with me over the years.

Don’t get me wrong. Consulting shops are not the problem. The market has set up a certain incentive structure and people operate within it to the best of their knowledge and abilities.

What I’m noticing, however, is that many don’t understand the opportunity cost of dumbing down the work they do from the standpoint of their market worth, personal happiness and long-term career. With the benefit of experience across many companies, bubbles and crashes, I’d argue that:

  • An awesome mobile hacker can make more money in an early-stage product company than in a consulting company but, more importantly, they’ll do this while having more fun and positioning their career better.
  • Great mobile developers don’t understand how much their career is suffering by them not investing in becoming awesome mobile hackers.

If you don’t trust me, talk to a top recruiter or some of the top geeks at the companies you wish you worked at.

The fine print: if you’re an awesome iPhone or Android mobile hacker who likes to solve hard problems that have never been solved before and doesn’t get nightmares from the thought that tens of millions of people will use your code daily then, hell, yeah, I want you on my team.

[Update] I’d like to highlight a point from the comments below in response to some private questions. I am dead serious about giving $10K to the first person who introduces me to someone I hire and I mean that not just for these positions but for any position I am also using recruiters for. It’s only fair to acknowledge the huge value that the right referral can bring to a company.

Posted in iPhone, Mobile, startups | Tagged , , , | 7 Comments