How To Work with your Technical Advisor

A strong relationship with a technical advisor can benefit all early-stage founders who are building technology product, whether you are using a contractor, off-shore team, or full-time staff. And in later stages, a technical advisor can continue to be a trusted ear for you, and a useful resource for your own technical team.

Through my work as an independent advisor, and with organizations like Mass Challenge, Founder Mentors, and NEVCA’s Critical Mass, I’ve been a compensated advisor (cash and/or equity) to at least a half-dozen startups, a pro-bono advisor to a few dozen, and an occasional advisor to hundreds.

Finding A Technical Advisor

You want to find an advisor who has deep technical experience, especially in areas you care about (big data? user-generated content? mobile applications?) But skip techies who are coming to you with an agenda. You don’t want them pitching their pet technologies, but rather offering the best solution for your unique business.

Often, you can reach out to strong technical leaders (CTOs usually) at other startups in your area (or remote, doesn’t much matter if the communication skills are strong). Pitch them on your idea, let them know why you need their help. A genuine interest in cultivating the best technical operation you can goes a long way towards making us want to help you.

Also, take a look at communities like Founder Dating to find strong tech leaders who are looking to engage full or part-time with new ventures. Most of my full-time roles began as technical advisor relationships. You never know, but you might even find your next great co-founder if things work out.

Make The Most of an Advisor

No matter how you find an advisor and choose to structure an advisory arrangement, here’s some advice from an advisor’s perspective on how you can get the best out of us.

  1. Show a genuine interest in the tech and execution side of your business. We get excited by your entrepreneurial curiosity, and we’re proud of the tech and product experience we bring to the table. Ask us questions, dig in deep. We’re here to discuss with you, not to lecture at you. It’s not useful for anyone if we are spoon-feeding generic answers across the table.

  2. Do your homework. It’s demoralizing to be asked questions that Google can answer faster and more completely than us. Don’t ask “How do I set up a Google Apps mailing list?” until you’ve taken a swing at it. If you come prepared into a conversation, it’s more productive and enjoyable for everyone.

  3. Ask “Why” Since you’ve done your homework and have a sense of what your options are, we’re happy to tell you which option is right for you. Unfortunately, not nearly enough of my advisees follow up with “why?” You should want to know why that’s the best option for your business or for your team. Why should you want to know?[1] Because of teach a man to fish…, and because your tech team will respect you more if you understand the why.

  4. Teach Us Back. We’re not working with you for our health, or because of a community service court order. We think you are smart, interesting, and have something to teach us too. Make sure this relationship is a two-way street, and don’t be surprised when we turn the tables and start picking your brain in return.

Stuff to Avoid

Here are some lessons founders and I have learned the hard way. Heed these pitfalls and everyone will get more from the relationship.

  1. Stop Pitching Us. You wouldn’t believe how many times I sit down for coffee with an advisee, only to have them spend 45 minutes telling me all about how the business is progressing, what the latest product ideas are, how much money they are definitely going to raise, and why it’s all going to change the world. There’s a time and an audience for that, but you’ve just wasted a whole meeting with someone who was there to help you, and you’ve gotten no value out of it.

  2. Don’t get defensive. We are spending our valuable time helping you out because we want you to succeed. We aren’t a competitor, we aren’t your boss, and we don’t have a hidden agenda to sink your idea. If you succeed, we look good and we’re proud to be associated with your success. Take our advice for what it’s worth, and then implement it or not. You are running the show here, no need to get defensive.

  3. Don’t be excessively legal. Okay, so that doesn’t mean be illegal, of course. Rather, don’t start shoving NDAs and IP Assignment agreements at a technical advisor early in the relationship, or ever for that matter. Tech people are the most skeptical bunch when it comes to politics and legal mumbo-jumbo (we incorrectly believe we would never use such litigious instruments if we were in your shoes). If you do want to stamp an agreement to protect both parties, keep it simple. Check out the Founder Institute’s FAST for a good starting place.

  4. We’re not your code monkey. If you are secretly hoping that you can get your technical advisor to fix your team’s code, or to build some part of your app in their advisory hours, put that thought aside. I had an advisee who actually asked me to re-install Windows on a laptop in their office, a task I thankfully managed to side-step. Many advisors will be happy to establish a separate consulting agreement if you want to pay us by the hour to get more hands-on. Keep those two parts of the relationship separate and everyone will be happier.


  1. See what I did there?  ↩

Foolishly Pretending to Know Tech

An entrepreneur asked me this week (paraphrasing), “I’m a non-technical person, but I do have some experience a ways back with HTML, CSS, CMS systems, and QA. Should I point that out when courting technical talent? Or will mentioning it seem irrelevant or worse?”

It’s a good question because I see people mis-handle this all the time. I see business people overplaying their technical background, saying things like “Well, actually, I used to be a developer”, or joking “I know enough about web development and databases to be dangerous”.

I know you mean it in good faith, as a geeky fig-leaf, a shared experience you hope will break the ice. But if you catch yourself saying these things, quit it!

Show, Don’t Tell

Unfortunately, mentioning your brief (or even deep but out-dated) brushes with technology, when you are first meeting technical talent, usually makes you come off as some combination of desperate, self-congratulatory, insecure, or obnoxious.

Imagine if the tables were turned. A technical developer announces in an interview setting, unprovoked, “I have actually messed around a bit with marketing copy and branding for a friend’s retail project, so I know enough about marketing to be dangerous”. Sounds stupid, right?

One of two things is true about your technical experience:

  1. It’s irrelevant, and you’ll be happy you kept your mouth shut.
  2. It makes you a better communicator, leader, and collaborator with your technical team. And that will be apparent from day one!

Tech talent is very adept as sniffing out BS. Rather than come across as trying-too-hard, you have an opportunity to pleasantly surprise us. A founder I worked with recently (an ivy-league MBA, all business guy), was showing me the latest changes to their blog design, and I asked him who was working on the CSS. “I just did it myself” he replied, as if it was the least surprising thing in the world.

He had never given me any indication he had any experience (or even interest) in web development in the many weeks we’d worked together. Instead, he showed me, and rather than rolling my eyes at his empty statements, I found myself genuinely impressed at his depth and scrappy resourcefulness.

Trust Your Talents

You are a well-rounded individual. A founder with a wide array of talents and experience. Just like having read a book about sales will make you a better sales manager, any background you have in technology will be a valuable asset as you build a tech organization. Heck, equipping founders to work better with tech teams is why I created ClearlyTech!

Trust your talents, and show a genuine interest in extending your knowledge to make you a better collaborator. Anyone pretending to bring more to the table than they do is a turn-off, and your tech savvy is no exception to that.

The Tough Truth About Hiring Off-Shore

I get asked at least weekly whether a startup should use off-shore development resources to get started. The implication in their question is almost always the same: on-shore developers are probably better, but off-shore developers are demonstrably cheaper.

It’s Hiring, Stupid

The tough truth is: this all boils down to a hiring problem.

You can make sweeping generalizations all day about where the best developers live, but you are being unfair (and you know it…). There are great developers in the US, there are great developers overseas. There are terrible communicators in the US, and overseas (both bad in your native language, and bad at the art of communicating).

The biggest reason we hear so many horror stories about off-shore teams is that it’s hard to hire them.

  • It’s hard to hire someone you don’t trust.
  • It’s hard to trust someone until you really get to know them.
  • It’s hard to get to know someone you haven’t met in person.
  • It’s hard to get to know someone who speaks another language in another timezone.

If the tables were turned, and you were in Europe trying to hire someone in the US, you’d similarly be lowering your odds of finding a great partner. This has nothing to do with the quality of the candidate pool.

The Tyranny of the Off-Shore Firm

All the difficulties above are compounded by the typical engagement with an off-shore development shop. We like the consulting agency model, because on the surface it does a few things:

  1. Provides credibility that’s hard to establish with a remote solo developer
  2. Sources the best developers in their remote area, and trains them to work effectively with US companies
  3. Gives a legal and financial umbrella that saves our startup from a lot of complicated paperwork and international employment questions.
  4. Provides a trusted way to add more team members to a project as you scale (or more likely, the illusion of that.)

The best shops will be worth a little extra cost because they really do provide those benefits, and because they are doing quality vetting of candidates so you don’t have to.

The major downside, even for the good firms, is that they add a whole layer of administration between you and the developer with whom you are already having a bear of a time building a trusted relationship.

Getting What You Deserve

So the reason that onshore developers seem “better” isn’t because they necessarily are. It’s just because you have an easier time identifying the good ones via a healthy direct face-to-face relationship that’s less likely to be managed by a dev-shop. Sure, you’re looking at developers that are 1/4 – 1/2 the cost, but you are already behind the count in some serious ways.

All hope is not lost, however! You deserve the best, no matter how/where you hire. If you are going to work with an offshore development shop, be open about what makes it hard, and shamelessly demand the following:

  • A proper interview process. — Don’t let a dev shop manager assign someone to work on your project. You absolutely have a right and responsibility to interview candidates that will work for you. You’ll get push back because the dev shop has to pay for the candidate’s hours to interview with you, whether or not you ultimately engage. Make that their problem, it will incentive a manager to put only highly qualified candidates in front of you.
  • Reference checks. — Ask for reference checks from other US companies that have worked with a candidate developer. You’d expect the same for any team member, right?
  • Trial periods. — If a developer isn’t kicking ass 30 days in, make sure you have a clear path to change. Set expectations up front that your business is too important for you to be stuck with a development resource you don’t “click” with.

You’d get all of these advantages with a developer from your local city. So don’t be crazy and try to make do without them in an off-shore hiring situation where the cards are already stacked against you.

I’ve worked with some awesome off-shore resources, just as good as co-located US teams. Make sure your hiring process doesn’t encourage low quality in addition to a low price.

Rapid Engineering Growth is Not a Business Strategy

crowd

BrightRoll CEO Tod Sacerdoti recently published a totally mis-guided article on How To Compete With Google.

In it, he asserts that in order to compete with Google in a space they dominate, you must have two things (only these two things, Tod? The rest of us have been dramatically over-complicating things, I guess!)

  1. have a world-class engineering team
  2. grow this engineering team at a rate much faster than Google’s

I’m with him all the way through “have a world-class engineering team”. Sounds great, and everyone should strive for that. However, the article goes south in three key ways:

  • The analysis that rapidly growing your engineering team will ensure success is completely backwards.
  • The strategy of beating your biggest competitor by emulating them is fundamentally flawed.
  • The tone set by this article is a quick way to turn off the best engineers from wanting to join your company.

Large Engineering Staff is an Effect of Greatness

Unfortunately for all the entrepreneurs who will be fooled by it, Sacerdoti’s analysis is backwards at best. And the assertion, that proactively hiring engineers faster than Google is the best way to make your company successful, is non-sensical and irresponsible.

Great companies have quickly growing engineering teams, no doubt about it. But rapid engineering team growth is the effect, not the cause of their success. It should come as a surprise to no one that great companies are growing rapidly. Full Stop.

In his article, Sacerdoti hand-picks sets of statistics about engineering headcount[1] at companies he admires. Then he analyzes two totally conflicting metrics.

  1. Percentage-growth in engineering team size
  2. Revenue per engineering head

I’ll tell you what: the quickest way to ruin your market-cap per engineering head is to over-hire engineers ahead of revenue growth and business model success. Ask the thousands of wildly successful companies who tried this approach. What’s that? …Not coming up with any? …Exactly.

Further, in rapidly succeeding companies, it’s not just engineering that’s growing. Run the same analysis on Sales, Accounting, Client Services, and Administration. No one will be surprised to learn that the most successful companies are growing in all dimensions ahead of their less-successful peers.

The truth of the matter is that great companies are growing rapidly. In healthy companies, that growth is a lagging indicator of their product uptake in the market. And anyone who suggests that hiring rapidly is a leading indicator of success has it backwards.

Stop Emulating Giant Entrenched Competitors

Too many startups make the mistake of trying to compete directly with an entrenched industry giant by emulating the way they build products, hire teams, run sales, or promote company culture. Startup leaders do this because it’s easier to be a follower than to dig deep and identify your own path to success. But the harsh truth is that you can pretend to be Google for years, and it won’t make you a great company (no matter how many engineers you coax through the door).

If you insist on architecting your company based on Google’s hiring ratios, the likely outcome you are hoping for is an acquisition by a large company that’s looking for a Google impersonator to plug into their organization. And even that strategy is made more difficult by hiring too many engineers, because the money you need to raise to support an engineering staff of 100+ will price you out of the market for an acquisition by all but the largest tech companies.

BrightRoll may well be hiring at a faster percentage growth rate than Google (but Tod, don’t be too smug about that, when 6 engineers = 10% growth for you). Let’s just hope that they have the product strategy, leadership, culture, and revenue growth to properly support it.

Engineers Don’t Trust This Approach

Finally, if you are in the enviable position to rapidly grow your engineering teams, do yourself a favor and don’t publish articles like Sacerdoti’s. Nothing turns off great engineers like being told they are a commodity, a hiring statistic, a denominator on the CEO’s confusingly quantified strategic plan.

Great engineers want to work on small teams where they can have intellectual control over projects with huge impact. Engineers most admire a company like Instagram, where tight clever engineering can support a great user experience at huge scale with only a dozen engineers.

Growing your engineering staff by 50% year over year will put huge strain on the existing staff, both by de-focusing their attention, and by diluting their equity stake. No one likes the interview process less than developers. And once a new hire is made, the overhead of having to bring that person up to speed is in direct conflict with the pre-disposition of great engineers to put their heads down and productively write code.

If you want your existing team to support you in your hiring efforts, lead with vision and opportunity, and let them come to you begging for more resources to accomplish it. That’s when you know you’ve nailed it, and it’s time to grow.


  1. He is suspiciously quiet on his actual methodology for calculating engineering headcount based on LinkedIn data. What constitutes an engineer? Are we only counting R&D engineers, or also Sales engineers, Tech-support engineers, QA engineers, and data scientists?  ↩