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.

3 Rules for Choosing Startup Technologies

Black, White, and Oh-So-Gray

Despite our more impassioned wishes, technology choices (like all worthwhile choices in life) are rarely black or white.

Show me a piece of technology advice on the Internet, and I’ll show you three pieces of conflicting advice. Such is the nature of both debating on the Internet, and making decisions in a rapidly evolving and still relatively nascent industry.

I see founders all the time paralyzed by technology choices, deciding to wait to build until the right tech falls in their lap. Or deciding to keep up with horrible home-grown solutions just in case some software package might not meet exactly their needs.

How To Make A Technology Choice

When in doubt, follow these three rules:

  1. Choose tech that has lots of customers like you and a thriving ecosystem. Avoid solutions that are only used by the Fortune 500, or by the one pre-revenue startup that hired the guy who built the tech in the first place.
  2. Choose tech that’s specifically designed for your purpose. Avoid solutions that try to solve all your problems with one monolithic package.
  3. Choose tech that your developers are excited about. They will work harder, faster, and more creatively with tools and services that inspire them. Avoid forcing anything on your team that will be an excuse for building anything less-than-awesome.

Embrace the impossibility of a one best choice, and relax. Choose with informed data, and your gut. There are as many ways to solve a given technology problem as there are technologists, so chances are good that whatever informed choice you make will be capable of delivering for you.

Only You Can Choose

Choices aren’t made by committee (at least not smart choices…)

Make a confident choice, and go solve some problems with it!

Working With Makers

As you grow a team of developers, designers, and other creatives (yes, programming is creative. Don’t make me explain it to you), it’s crucial that you pro-actively remember to treat your team as the makers they are.

I’m not going to recap the different between Makers and Managers, because the venerable Paul Graham, as usual, said it best.

Go read Paul’s short essay on the topic this very minute.

And for you visual learners, I offer this gem of a diagram to aid your learning:

A Day In The Life Of A Programmer

You might be forgiven for assuming I’m being funny, but I assure you, it’s very true. Underestimate the power of its message at your company’s peril!

Build, Borrow, or Buy


Almost every week, it feels like it’s time to add a new piece of technology into the mix. That could mean a new product feature, a project management tool, a business intelligence package, a new email system, often things on our tools list.

Making Something from Nothing

Whether you are replacing something that’s broken or conjuring a new component into existence, you must consider three paths:

  1. Build – you can always open a blank file, pick a programming language, and go to town. You’re only limited by your imagination, skills, and time. This is called “green-field” development. The wide-open world is your oyster….just don’t screw it up.
  2. Borrow – the movement of free and open-source software proffers us a great variety of solutions to common (and sometimes incredibly niche) problems. Strong caveats always apply…specifically, you’re on your own. No support, no warranty…[1]but also no cost, and often tremendous, uncompromising power.
  3. Buy – for almost all your needs, there’s a partner out there that will charge you for their solution. This could be a software license, a software-as-a-service offering, outsourced development resources, a consultant, or a support contract.

Build Your Business Pillars

Every business has pillars. These are the central support beams for your success, those things that define your unique opportunity in the marketplace. You should Build your pillars. They represent the largest differentiator for you, the most important components of intellectual property, the areas in which you’re innovating, and the things you’ll do better than anyone ever has before.

Let’s take Netflix for example. They built a few clear technology pillars:
1. Logistics – Netflix grew off the bet that they could create a more delightful customer experience than renting DVDs from your local video store. Critical to that was figuring out how to handle logistics and inventory management for millions of DVDs shipped to and from residential consumers.
2. Recommendations – The best way to beat the experience of browsing the shelves at Blockbuster (may it R.I.P.) was to provide personalized recommendations. This recommendation engine is such a critical component for Netflix that in 2009 they ran a $1M Contest challenging hackers and academics around the world to improve their recommendation algorithm by 10%.
3. Digital Delivery – Netflix has evolved at the forefront of the streaming video revolution, and have invested heavily in building streaming services in the cloud.

None of these three pillars for Netflix are commodity “solved problems”,[2] and it is absolutely core to their future business, so Netflix was right to develop these pillars in-house.

What are your 2–5 pillars; your “secret sauce”? Here are some anti-hints to help you out:

  • Are you building a photo sharing app? You shouldn’t be in the business of designing your own email sending infrastructure.
  • Are you selling enterprise software and need to keep track of your clients? Definitely don’t go and build an in-house custom CRM solution.
  • Are you storing less than a terabyte of data with well-defined access patterns? Don’t write your own database.
  • Are you building a subscription data analytics service? Please don’t waste time building a custom subscription billing system.

These may seem obvious to you, but I’ve seen each of these cases in real life. And in all of them, the technical teams had a gleeful pride in their accomplishment, which was sorely misplaced. They’d spent valuable development resources on things that aren’t key pillars which will make or break their business. Entrepreneurs have a super-power for convincing themselves their problems are unique. Pro Tip: they’re not.

Borrow Your Team Tools

If it’s not a pillar for your business, it’s a tool, a commodity, a pluggable solution. Stretching our architectural analogy, we’re talking about the drywall, wiring, and windows for your building. Probably not what you want your team spending time on.

You should borrow all the tools, libraries and services you can in order to help your team focus. You must stand on the shoulders of the open-source community and benefit from all it has to offer.

Unless you have defensible special circumstances, you’ll almost certainly borrow things like:

  • programming languages (Python), web frameworks (Rails), and javascript libraries (jQuery)
  • databases (MongoDB)
  • source control (git)
  • application monitoring (nagios)
  • data exchange formats (json)

When in doubt, search GitHub for your current needs (web page animations? machine learning neural nets? wrapper libraries for legacy APIs?), and more than likely you’ll find numerous libraries in your language of choice to help you out.

Your Soldiers of Fortune

It’s probably cost-effective to spend money in a lot of areas, think of them as your far-flung mercenary empire. A whole army of vendors, consultants, commercial software providers, and SaaS[3] solutions is available on the cheap.

The construction worker on our fictional building definitely doesn’t build his own hammer or forge his own nails. He doesn’t design his own invoices or run his own website. He sub-contracts to a specialist when it comes time to build the swimming pool. And he buys custom site-management software to make sure his project stays properly staffed and on-schedule.

Here are a few reasons you might Buy instead of Building or Borrowing:

IT, Management, and Internal Tools

You will use a huge set of internal tools that are worth spending a small fixed fee or subscription rate for. Often these are things like Google Apps which you pay for by the “seat”, so they scale with the size of your workforce. Or awesome project management tools. Or web-based wireframing templates to help describe your product and rapidly iterate it.

Special needs for high-quality technology solutions

Perhaps you have a need for a hundred terabytes of data, high-availability, and huge analytics joins across billion row tables. In that case, opting to pay six figures per year for HP’s Vertica might make great sense.

Often these special needs are closely tied to the pillars of your business, but the technical needs are so sophisticated, your custom-built solutions will sit on a foundation of commercial software packages.

Delegation Operational Overhead

Don’t want your team spending their time on ops projects? No problem, someone out there will run it for you.

I regularly use Amazon Web Services. For this very site, I pay for EC2 to run machines for me, saving me from ever having to worry about provisioning hardware or leasing datacenter space. I also sometimes use RDS-hosted MySQL. It’s not that I don’t know how to effectively manage a MySQL server[4], but it’s worth a few bucks to not have to do it myself, to have them run backups and updates for me, and to have 1-click access to change the size of the DB.

Paid monitoring solutions like ServerDensity, New Relic, Pingdom, and on-call systems like PagerDuty, provide loads of operational support out of the box. As a bonus, they help guide your team towards best-practices rather than having to invent that from scratch.

GitHub spares me from having to do source code backups, and streamlines collaboration for my teams without having to manage and run a centralized source code master node.

This list goes on and on. It’s the most represented on our list of recommended tools, and for good reason. Infrastructure/Software as a Service models have exploded in the last decade, and offer the biggest single reason why the initial capital costs of building new online applications has dropped so dramatically.

Single-Serving Contractors

Sometimes you need specialty services that don’t warrant hiring internal resources. Maybe you need a new blog design template for your company blog, or a new logo design. You find a contract designer or development shop.

If you need expertise to build a custom data taxonomy of cuisines, hiring a grad student from a culinary school for the summer to do the research and produce a proprietary report for you would satisfy the need nicely.

Or perhaps you want a feature on your new blogging platform that automatically recommends content to younger readers based on reading-level of the article content. You could do a project contract with a PhD data-linguistics specialist to build you an algorithm to power that particular feature.[5]

Consultants and Contractors are best for:

  • Short bursts of work (an analysis project)
  • Part-Time senior expertise (contract CFO)
  • Legal or regulatory certification is required (Your lawyers, or a HIPPA compliance specialist)

It is not a good idea to hire a contractor long-term for a role that you should be filling in your organization. If the function would be best served by a great team member, make it happen by whatever means necessary. Having a great dedicated team is a Pillar of everyone’s business.

It’s a Merry-Go-Round

As your company grows, all these decisions will be revisited. Something that you buy at the beginning you might decide to borrow or build once you have additional engineering resources. Something that you contract for now might become a commodity in the near future, and become better by a SaaS service, or even an free code library.

And of course development tools, software services, open-source solutions, and your access to great people are inevitably going to change over the years.

Don’t get overly wedded or sentimental about prior choices. Boldly revisit decisions as your business shifts. Lather, Rinse, Repeat.


  2. At least not solved at Netflix scale, an important consideration when figuring out what’s a pillar for you and what isn’t. There are all sorts of things you would never build, but Google has to, like bespoke database solutions, merely because they are operating at an unprecedented scale.  ↩

  3. or PaaS, or IaaS  ↩

  4. I’ve owned and operated literally dozens of MySQL standalone and replicated setups over the years, tables up to a billion rows.  ↩

  5. Of course, your contractor might just go and Borrow the solution in the form of an open source library  ↩