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.

Building a Simple Olympic Medals API


I’m shamelessly excited about the upcoming olympic games. I’m a sucker for both the competition and the cheesy human-interest stories…. I thought the games would make a good excuse to show how a simple API can be built and launched from scratch with modern tools.

Put on your propeller beanie and let’s take a gentle geeky look at how I built it.

Olympics Medals API

The project was to launch an web-based API that returns JSON data on the current medal count for the Sochi 2014 games. In plain english, that means a URL:

which returns raw data that can easily be consumed by another computer program.

Why would we want this? This is very similar to almost every API that powers mobile apps today. Most iPhone and Android applications are constantly visiting URLs like this to get the data they need to update views in response to user input, loading a new screen, etc. These things power nearly every interaction you do on mobile, and a good chunk of the web too.

In our specific case, we return JSON text as seen below, with the latest medals counts for all the olympic countries. You’ll get the full data if you click the link above.[1]

      "country_id": "united-states",
      "country_name": "United States",
      "rank": 1,
      "gold_count": 12,
      "silver_count": 14,
      "bronze_count": 6,
      "medal_count": 32
      "country_id": "germany",
      "country_name": "Germany",
      "rank": 2,
      "gold_count": 8,
      "silver_count": 16,
      "bronze_count": 1,
      "medal_count": 25
    and so on, for all 94 countries represented.

There’s also another URL for retrieving the medal counts for a particular country:

That one returns a very little bit of text:

    "country_name": "United States",
    "rank": 1,
    "gold_count": 12,
    "silver_count": 14,
    "bronze_count": 6,
    "medal_count": 32

Getting the Data

This app was a fun reason to try out a newly launched tool called Kimono. They offer a service which scrapes structured data off web pages for you. I created a Kimono scraper in only a few clicks which retrieves the raw data directly from Wouldn’t have been hard to do myself, but developers love shortcuts wherever we can find them.

It’s worth noting here that my API is a wrapper for a Kimono API, which is scraping the official Sochi website, which is displaying raw data from the International Olympic Committee medal standings API. These kinds of services-built-on-services are what makes the modern web so exciting and powerful, while simultaneously confusing and often fragile. If I were building a real production-quality API for olympic medal standings, I’d almost certainly try to license the raw data source to make my app faster and more reliable. But this approach will work for our purposes, and allowed me to get the whole API built and deployed in only a couple hours.

Building the App

I chose the lightweight Ruby Padrino framework for this app. It doesn’t have as many advanced features and support as something like Ruby on Rails, but it’s fast and easy to work with for a tight small project that doesn’t need a fancy front-end or even a database (though you can do all that with Padrino too).

You can find all the source code for this application open-sourced on GitHub. If you haven’t poked around at an app like this before, indulge yourself, and go take a look at just three files:

  1. The main application file shows three simple URLs. Our two API endpoints, and the root, which redirects to our documentation.
  2. The MedalData class which does the work of grabbing the raw data and arranging it to match what we return via JSON.
  3. A simple automated test for MedalData that makes sure future changes to my code or the Kimono scraper don’t break the behavior I’m expecting. This is a great example of how simple an automated test can be.

All the rest of the files in the project are just decoration, configuration, documentation, the boilerplate plumbing that Ruby and Padrino require to do the work. Not that hard, right?

Documenting the API

Developer tool Apiary maintains an open standard for documenting APIs like this one, called the API Blueprint.

I wrote up a similar description as above, but in their specified format, which is shown when a user visits

Simple documentation like this goes a really long way towards convincing others to consume your API. Developers love this stuff.

Deploying It To The World

I decided to launch it on the mind-bogglingly easy Heroku platform. I created a new app, ran some git commands (Heroku manages your code by using the git source control tool that your developers are probably using anyway), and voilà! Instant public application.

Technically, the Heroku app runs at, but I told it to answer to as well, by putting an entry in my DNS zone, managed by Amazon Route53. This may seem like a lot of moving parts, but wiring this kind of thing up is second-nature stuff to any full-stack developer worth her salt.

The whole process of setting this up on Heroku (including signing up for the service, setting up the app, deploying it, and changing my DNS) took about 10 minutes. There isn’t a faster way right now to deploy a low-volume application for public consumption.

  1. The code at the raw URL is not nicely formatted like our example, but another piece of code consuming this service doesn’t care how pretty it looks.  ↩

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.

Beware of These Five “SaaSumptions”


The intoxicating siren song of a new generation of Software as a Service (SaaS) offerings is a promise that you can bring awesome products to market faster than ever, or run your business operations with dramatically less friction. Heck, it’s what ClearlyTech Recommends is all about. But caveat emptor if you blindly assume that the latest greatest SaaS offering is automatically mana from heaven. Oscar Wilde taught us all what happens when we assume.

And so we present here the five SaaSumptions that may come back to haunt you.

  1. They’re free! Many SaaS offerings take a first-hit-is-free approach. Take the time to understand when the premium part of their “freemium” offer kicks in. Understand how much it will cost and what the ROI is before you do a deep integration.
  2. They will always exist. How sure are you that this partner will be in business longer than you will? How much do you trust them to tell you far enough in advance of an impending shutdown that you will be able to respond gracefully? Note: almost none tell you in their terms of service what happens to your data if they shut down.
  3. I can trust them with my private data. Data is at the heart of everything you do. Sales data, log files, billing invoices, customer information, user generated content, etc. Before you trust a provider to own a copy (or the only copy) of that data, find out if they do backups and have an appropriate disaster recovery plan. Consider doing regular exports of the data into your own backups. And consider what happens if their security is compromised. You will still be liable if all your customer information gets stolen, at least in the eyes of the marketplace, and potentially the law.
  4. Their service is up 24/7 What happens if you are serving traffic, but your partners are down? Maybe you are hosting all your videos on Amazon S3, or your images on Cloudinary. Make sure you know what your site looks like if those providers have a temporary hiccup. Murphy’s law promises that it will happen during your big marketing push, of course. Even if they are up, your SaaS provider might be hosted in another part of the country or the world, meaning that general Internet routing issues might cut you off from their services. Note: most don’t provide rock-solid SLAs, don’t expect to ever get money back if they go offline.
  5. They totally meet my needs. They might have exactly what you need right now. What happens as you grow and change? Make sure their other customers are like you, that will help ensure they have your best interests in mind. See if their customer support is quick in responding to your specific needs. Can they scale with you? Do they have international support? Be careful you don’t design your product around the services you choose. You owe it to your customers to give them a stellar product, even if you have to get custom to make that happen.

When it comes to picking SaaS partners, remember to pay particular attention to your pillars, as those are the areas where a bet on SaaS partners or a decision to build it yourself will matter the most. Beyond that, do your diligence, and design your dependencies on outside services so that you could shift to another one if business needs warrant it. The buck stops with you.

Don’t be afraid to go with SaaS (it’s a powerful advantage you have as a small company), but be smart about it.

Email in 2014 is Mostly Mobile

Email testing and tracking company Litmus published a great look at email client traffic in 2013. The upshot is that more than half of all emails are being read on mobile devices, and the trend will continue. Litmus finds a whopping 38% on iOS alone.

In response, you’d better be testing how your emails look on those devices, and doing responsive email design up front to make the best impression with all your email communications.

Email Client Market Share
Email Client Market Share

Rapid Engineering Growth is Not a Business Strategy


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?  ↩