If you want to attract top talent leave 25% of your job description unwritten.

Imagine walking into an interview and while you're going through the job description with the tech director he stops and says, "Ok here's the part where you fill out what you want to do."  




In fact, I've never met a great developer that didn't.  If the company they are currently working at isn't allowing them to do it, you'll see evidence of it through their Git repos, developer blog or some other side project.  Now just imagine if someone or some company gave them the opportunity to actualize their project as part of their regular everyday job?  You guessed it Charlie, they'd leave your sad @$$ company in a heartbeat.  

I think one of the things that's so attractive about many startups is that they are very well suited to provide an environment that fosters a developers ambitions and dreams.   Startups are great places to stretch a developers limits.  They also allow them to flesh out ideas without being claimed or owned by some giant corporations legal department well....mostly ;).  


Instead, this is how most companies are recruiting.

Hey you!  Come join our team.  We're awesome and what we're doing is important to us.  Come work on our stuff and make our company, product or service better.  In return you'll get {insert stupid company perks here}.   These days most technology workers have a choice.  They can leave your company for a line up of others waiting to hire them or simply start their own shop.  

This being the case, it makes sense to partner with them and get involved in their interests and ambitions.   You'll never create more loyal, happy and productive workers any other way.  


Is your developer holding you hostage?

Tell me if this sounds like a situation you're familiar with.  Once upon a time you hired a developer to write you a piece of software or maybe create you a website.  Now every time you need to make a change you need to go back to this developer to do it because no one else knows how. 

That's the situation many business owners and founders find themselves in and it sucks.  You're being held hostage by your developer and you can't make a move without them.  

** Important ** Before you read on I feel it's important to say a few things.  Not all developers hold you hostage because they are bad people.  Many times it originates from fear on the developers part.  Fear of being replaced, fear of leaving their comfort zone or even fear of criticism from other developers.  If you think this is the case, you may want to address those issues up front before trying to replace the person.  


How can I tell if I'm truly being held hostage? 

YOUR DEVELOPER WON'T DOCUMENT THEIR CODE OR TEACH OTHERS HOW IT WORKS.  Whether you're building a website or a SaaS application you should demand that the developer document their code and explain in detail how the application or site works.  If the developer won't do this find another one.  One of the oldest tricks in the book is to create client dependancy by being the only one who understands what's going on.   

Example from my experience: Recently I came upon a situation where the client had the same developer for over 15 years because he refused to document the 80K+ lines of code in the application.  Each time they hired a new developer and they came close to figuring things out, he'd tell the business owner the person was incompetent and demand they were fired or threaten to leave. I'd say this dev has them firmly over a barrel with little chance for escape. 

YOUR DEVELOPER HAS CHOSEN AN OBSCURE OR OUTDATED LANGUAGE.  Letting a developer single handedly choose the language to build your application with is just plain stupid for a number of reasons.  Languages and frameworks go in and out of vogue all the time.  Because developers are engineers at heart many of them want to be using the latest and greatest technology or sometimes even feel pressured into using them for fear of appearing behind the curve.   This results in situations where languages or frameworks quickly become outdated, lose support and fail to receive updates. Javascript is a great example of this as new frameworks are popping up all the time. Last week it was Angular and Ember, this week it's Meteor and Rendr.  On the opposite end of the spectrum are developers that are holding on to outdated and dying languages like Perl, VB, Ruby or Cobol to name a few.  Before embarking on development do some research and find out how easily you'll be able to find other devs to work on your project.  If you can't find other developers easily or you find references to the language heading out the door, find another dev. 

EXAMPLE FROM MY EXPERIENCE: I once sat in with a client who was talking to a web developer about how they were going to build the company website.  While a simple CMS like Wordpress would have sufficed, the developer instead pushed for an exotic build utilizing some custom frameworks he'd written.  While it did result in a great site, no one in the company can make a change to it for fear of breaking it. When they need an update or change, it costs them $150/hr and they have to wait on average a week to get it done.  

YOUR DEVELOPER MAKES UP REASONS OR EXCUSES FOR WHY CHANGES CAN'T BE MADE AND USES TECHNICAL JARGON TO BAFFLE YOU.  Technical jargon is part of our industry but it shouldn't be used to baffle you with bull$h*t as the saying goes.  A good developer should be able to explain things in layman's terms, if they can't or they won't you might want to consider someone else.   If you're already stuck with a developer and you don't understand their response to a question get it in writing.  Once you receive it in writing, ask another developer to review it, post it on Reddit or Linkedin Groups and other devs will be only to happy to chime in I'm sure.  I also recommend going to Wikipedia and educating yourself, it behooves you as a business owner to understand a little about the technology that powers your business.  Get an education and you'll be a lot more prepared.   


How most founders kill their businesses in 10 easy steps.

Over 10 years of recruiting has allowed me to peer into the inner workings of 100's of companies and given me a perspective most people will never experience.   During my intake process for a new client I embed myself in the company. I find out why people like working there and seek out every closeted skeleton that could bite our recruiting efforts in the a$$.    During this time I have witnessed the very best ways to manage a business and the worst.  Most times there is only one person to blame or praise for this and it's the founder or CEO.  

here is how most founders end up killing their company

Several years ago while working for a casual gaming company in Europe I was asked to recruit senior level management for the studio, this included senior Project Managers all the way to Vice-Presidents.   It was a great company and still is to this day but the same couldn't be said for one of their competitors.   One morning I opened my email to find I'd had a VP from this competitor apply to one of my jobs, the guy had a brilliant background and I was stoked. Doing what I do I called this VP up and asked why he was looking for a change, this is the story I was told.  

When he first joined the company business was strong, the founder had a solid vision and times were good, but as competition increased and the business landscape shifted it got harder.  This founder had done his best to surround himself with incredibly intelligent people but when things got tough for the business he did what so many other founders do.   He stopped trusting his people to take care of the business and was of the opinion that he was the only one that knew what do to, he was the founder, the visionary....god.  Unfortunately I see this behaviour all the time and it goes a little something like this.


  1. Founder creates successful new business.
  2. It's smooth sailing for a while. 
  3. Founder hires smart people and mostly lets them run the business.
  4. Competition or changes in the market create challenges for the business. 
  5. Founder, freaks out and starts tightening the reigns on his managers. 
  6. Founder now oversees every aspect of the business and decisions cannot be made without his approval. 
  7. Managers, have been stripped of power, they now sit in meetings waiting for instructions.
  8. Managers stop thinking for themselves and become robots.  The good ones can't stand this and quit. 
  9. This quitting freaks out the founder so his grip tightens and micromanaging becomes worse. Employee confidence is shaken, more people leave the "sinking ship".
  10.  It becomes impossible to attract new talent and the BUSINESS EVENTUALLY DIES.

If you've ever started a company you know how hard it is to relinquish control of your baby.  To be truly successful though, you need to rely on other people to help you.   Even after Steve Jobs passed away Apple has continued to be successful and I doubt any of us here are as talented as that man was.  Your business can do without you and it can certainly do without your micromanaging.  To quote a currently popular children's movie...... Let it go, Let it go, let your managers run the show, let it go let it go you're not the almighty know it all.......



Why "Stealth Startups" are a really bad idea.

I think Eric Ries summed it up best when he said.  

"The most common objection I have heard over the years to building an MVP is fear of competitors - especially large established companies - stealing a startup’s ideas.

He then goes on to issue the following assignment to those wishing to remain in "stealth mode"

Take one of your ideas (one of your lesser insights, perhaps), find the name of the relevant product manager at an established company who has responsibility for that area, and try to get that company to steal your idea. Call them up, write them a memo, send them a press release - go ahead, try it. The truth is that most managers in most companies are already overwhelmed with good ideas. Their challenge lies in prioritization and execution."

Even better I once read the following quote on Reddit in response to a game developer who asked other experienced devs if he should remain stealth about his game. 

"It is far more likely that your game will languish from obscurity than be ended because a competitor ran away with your idea and executed on it first." 


why remaining stealth is a bad idea

  1. You'll turn off investors.  VC's don't like to be treated like children or have their time wasted. Their not going to sign your stupid NDA. 
  2. You'll miss out on potential partners and collaborators.  I once read a book entitled "The Luck Factor".  After interviewing 400 people, researchers concluded that the more people you knew and who knew what you were doing the luckier you were.  Don't tell people what you're working on and they can't help you. 
  3. You'll lessen your motivation. Social pressure is an awesome motivator.  When things get hard and the always do you it's harder to back down and quite once you've announced to the world that your'e going to bring some new awesome app or game into the world. 
  4. You lack user input and feedback.  Creating great products means talking to lots and lots of customers, getting feedback and having users test your product.  If you develop it in a secretive stealth vacuum you miss out on this important feedback.  Do you want to spend 2 years developing a product to find out no one needs or wants it? 
  5. It makes conversations with friends pretty boring.  Hey man, "what are you working on?" Umm, I can't say........(crickets chirp).


Are you a technology company or a sales & marketing company?

About 6 months ago I attended a workshop given by the great Boris Mann of Fullstack.ca Vancouver.  At one point we were talking about growing your startup and he asked something that really hit home.   

"Are you a technology company or a

sales & marketing company?" 

Think about this for a second.  Everyday it seems a new app comes out just to compete with another app that solves the same problem.   It's less about who has the best technology, than who can reach customers the fastest or secure partnerships before the other guy does. 

If you build a great app no one will beat a path to your door.

I've worked for over 30 companies now, many of which who've had some amazing tech and it's true, no one was beating a path to their door.  We took it one customer at a time building on our base of loyal early adopters.  We spoke to as many users as possible trying to understand their problems and translating their feedback into features and improvements to the product. 


Developers and designers, you'll need to embrace marketing  to be successful

As much as that sentence may have pained you to read, it's true.   You can't solve a lack of customers problem by; 

  • Adding new features to the app. 
  • Refreshing the interface. 
  • Giving your website a redesign. 

That said, I see this behaviour all the time.  Have your ever heard the old saying that the definition of insanity is doing the same thing over and over but expecting a different outcome?   The quicker you face the fact that you have a marketing and sales problem not a technology problem the better off you'll be.....as painful as that will be to accept.  

I say painful because it's no fun accepting the fact that your current set of skills can't help your company, or realizing that you're going to have to do things that are really uncomfortable for some of  you. (cold calling strangers sound like fun to anyone?) 


you have 2 options to solve your problem

You can either learn to be a marketer or hire one who know's what they're doing.  Having witnessed this scenario enough times I recommend the second option.   DONT! cheap out on this person, all too often I see some startup hire a "junior" marketing person to tackle a senior level marketing problem.  This is a waste of time and you're better off not doing it.  Would you let a junior coder hack directly on your app?  Of course not, so why would you risk the future of your company on someone with very little experience?  Good marketers will come with lessons they've learned from past clients, they'll hit the ground running, come with useful contacts and easily pay for themselves.

The question of course is, where do you find these people and how do you know they are the real deal and not just selling you, after all that's what they do for a living?   That my friends will be answered in my next post, How to hire a marketer or salesperson for your startup.


The 8 most expensive languages to code your app in.

As a startup founder there are many factors you should take into account when choosing the language to code your app in.  Salaries and available talent pool should at least be in your top 3 though. 

The most expensive language with the hardest to find programmers is..

When a company is in it's startup phase there are a few things they are generally always short on. The first is cash and the second is time/available people to work on the project.   If you want to make this problem worse code your app in Ruby.  Ruby is currently the most expensive language to code in based on programmer salaries.   You'll also find that it takes an incredibly long time to find a good Ruby programmer.  Presently in Vancouver the time it takes to fill a vacant mid/sr Ruby role is almost 3 months.  Compare that to Javascript, and coders seem like they're falling out of trees. 

For comparison sake, lets look at a few other languages as compared to Ruby and see what the cost and average time to fill a mid/sr. vacant role is. 

  • PERL - 34% less expensive and about 3 weeks to fill.
  • C# - 23% less expensive and about 3 weeks to fill. 
  • JS - 20% less expensive and about 4 weeks to fill. 
  • C++ - 17% less expensive and about 1.5 months to fill. 
  • JAVA - 16% less expensive and about 4 weeks to fill.
  • Python - 9% less expensive and about 6-8 weeks to fill. 
  • Obj. C - 2% less expensive and about 8-10 weeks to fill. 



Startups need to move fast.  If you're stuck waiting to find programmers either because they aren't available or you can't afford them, your product can't move forward.   The sales team won't be able to close deals and you'll burn out your investment money idling while waiting to hire new blood. Make sure when choosing your language you think seriously about your future hiring needs.  When anticipating how long it will take to find new staff, double the amount of time you think it will actually take. 

Personally I'm actually quite a big fan of Ruby, but that certainly wouldn't be the deciding factor in whether or not I chose to use it for my app.   It shouldn't be for yours either. 


Startups, don't trust your early adopters.

As a startup tech company, early adopters and innovators are your lifeblood.  These customer groups are the ones that are willing to try your product in it's early MVP stages, support you along the way to mass adoption and are most willing to talk to and engage with you....and therein lies the problem. 


Early adopters and innovators represent a very small percentage of who your actual customers are going to be.  

If you follow Lean methodology you know customer interviews are extremely important to the process of product and solution development. However, the majority of customer interviews and feedback come from a startups early adopters and that is the problem. 

You are developing solutions to solve the problems of your early adopters.  

The problems the late majority of your customers will have, are not the same as your early adopters.  But for reasons like customer traction, early revenue and because we're too chicken to reach out to strangers we develop for them.  

The words you must watch out for. 

Almost all of the customer interviews I've done for my clients included this key scenario spoken by an early adopter.  "I've done or tried to create something similar to your product by mashing/hacking together these other things or technologies." 

Your product + his dreaming + tinkering = his problem solved. 

Your early adopters do not define the use case for the problem your product will solve for the majority.  It is when you remove the need for DREAMING + TINKERING that you have a solution that will be ready for the masses. (mostly)


How this effects marketing and branding.

The discussion around brand and positioning is an important one, but given the information above if anyone in your startup uses the word Brand not in conjunction with Russell or New, stop them immediately.  


By now we know the information you are receiving about your product or solution is most certainly skewed towards the early adopters group.  Again, what this group wants to see and hear about you is totally different than what the larger masses will.  I suggest putting some marketing out there but don't fall too in love with it and PLEASE PLEASE do not waste your time with numerous revisions and cosmetic changes to your website or product unless usability is improved.  

What can marketing do then? If you have a strong marketing manager or team send them out into the world to find customers that won't use your product in it's current state.  Interview them about what they currently are using, stalk the competition and inventory their strategies and messaging.  Whatever you do though, don't trust the early adopters.


Growth Hack: Hack job boards like Monster.com to create refined customer prospect lists for your startup.

Lets say you happen to be a startup that produces an app for Salesforce or a plugin for Wordpress.  Wouldn't it be great to have a big list of every company that uses either one of those tools?  

Option: 1 - Go buy a list from some list vendor or biz dev company.  Sure, it's an option but if money is tight check out option #2. 

Option: 2 - Go to a job board aggregator like Indeed or Monster.com. Pick a location and enter Salesforce.com as a keyword.  BOOM! You just got a list of companies that use Salesforce.com because it is a required skill in the job description.  

And here are the results ready to be imported with one these two free handy tools, Import.io or Data Miner a Chrome Plugin so easy your grandma could use it. 

My review of Quickmail, the best damn email automation system I have ever used.

Over the last year I've tested 7 different email automation programs for different business development teams.   Some were good, some sucked, some over-promised and under delivered but here's the one I liked best.  


Developed by an awesome dev named Jeremy Chatelaine in Switzerland, this program does what many other email systems twice the price promise but don't. 


  • Email using your Gmail Account.
  • Track Open Rates (more reliably than other systems based on my testing)
  • Create email sequences and follow ups that change based on the recipients actions. (LOVE THIS!)
  • Personalize emails with tags that import first names, titles etc. 
  • Split testing functionality baked right in. 
  • Import prospect lists from Google Sheets. 
  • Automatically poles a selected Gdoc for new prospects and adds them.
  • Tracks click rates on links in your emails. 
  • Track reply rates. 
  • Advanced email scheduling and send times. 

By far though the greatest feature about this system is the fact that it tracks open rates far more accurately than the other systems.  For example, when you email a prospect and get an out of office response or bounced address other systems track it as an open, not Quickmail.  

As digital marketers we need solid data to work with when A/B testing offers and scripts and to date the best email system I have found is Quickmail.io


3 Bulletproof Feature Confirmation Questions

When engaged in a sales call you may run into a situation where a customer states that they would buy your application except that it happens to be missing a feature or features.  This can be true but it can also be an excuse to not buy your product. (people hate rejection so it’s easier to use the missing feature line than just say no to you)    These questions will help you figure out if it is a legitimate shortcoming or just a put off. 

When a customers says they like your product but seem reluctant to move ahead with it because of a missing feature ask these questions to validate it. 

  1. Is that feature present in the application you currently use? 
  2. Who do you anticipate would be using this feature the most? 
  3. If we were to bump that feature up in our product roadmap and develop it right away, would you be willing to buy our product or give us shot?

If the customer answers: 
If the answer to question 1 is yes then you know you have a legitimate shortcoming.  If the answer is no but the customer say’s it’s something they want to see in the next application they buy you need to dig further.  It may not exist in your competitors products and you need to find this out.  It may be worth developing OR it may be a feature used by only one specific company.  Do the math and see if it’s worth it. 

If the answer to question 2 is the majority of the users of the app then GREAT you have a legitimate need.  However if the answer is only the person you are interviewing or talking to chances are it’s there own pet interest and not representative of the needs of the whole.  DON’T DO IT!

If the answer to question 3 is yes you are golden and I don’t need to say anymore do I?  If the answer is no you need to find out why and dig some more.  It may be an important feature but it’s just that they don’t want to or can’t commit to you.  Go back to questions 1 & 2 validate.