Docker, Inc isn’t Dead

Chris Short recently wrote up a piece entitled Docker, Inc is Dead, with a prediction that the company would no longer exist sometime in 2018.  It’s well written and he does a good job of running through some of Docker’s history in recent years.  Although I agree with some of his sentiments, I don’t think Docker, Inc will exit the stage anytime soon.  Here are some reasons I think Docker, Inc will live a healthy life in 2018.

Docker is Good Software

This was the first point in Chris’ piece, and he’s right.  Docker definitely helped widen the spotlight on *n?x kernels.  Discussions around namespaces, cgroups, lxc, zones, jails, etc… lit up across communities in different disciplines.  Dockers’ simple interface lowered the barrier of entry for non-administrators, and the developer community immediately added it to their workflows.  Docker released EE/UCP, and larger organizations jumped on board.  It “is” good software for developers, SMB’s, and large organizations, and Docker, Inc isn’t slowing down development efforts.


“I’m really excited to welcome Solomon and Docker to the Kubernetes community”.  Brendan Burns (of Microsoft, Lead Engineer of Kubernetes) definitely made me do a double take when he said that on stage at DockerCon EU a few months ago.  Many people I spoke to at the conference referenced that statement and saw this as a big blow to Docker.  “Who’s joining who’s community? ”  The thing is, the real purpose of Brendan’s talk was about the collaboration between companies, and the effort to make our lives as developers and administrators better.  The whole “it takes a village to raise a child” saying.  This village is composed of some of the brightest engineers from many of the world’s largest companies, and they’re all striving to make things better.  Docker and Kubernetes worked together, and the Kubernetes integration into UCP made perfect sense.

Docker has business

They don’t have a lack of coherent leadership.  They’ve received a ton of money, their marketing is great, and they’re acting like what they are;  a rapidly growing company moving into the enterprise market.  Were some of their keynotes awkward at DockerCon EU this year?  Yes.  Were there fantastic sessions from customers who shared real-life Docker success stories?  Yes.  Have they made some mistakes here and there?  Yes.  Have they moved past those and grown?  Yes.  If you’ve been around the block and watched small companies rapidly grow into behemoths, this is all typical.  Growing isn’t easy.  Their “Modernizing Enterprise Applications” mantra is perfect.  There are countless technical budgets from Fortune 10,000 companies that Docker, Inc will capitalize on.  The best part is that they’ll actually be making a positive difference.  They are not snake-oil salesmen.  These companies will probably see real ROI in their engagements.


Docker, Inc isn’t going to be acquired (yet) or close their doors.  There is a lot going on at Docker, Inc right now but they aren’t signs of a company that is getting ready for a sale.

It’s a company that’s based on OSS with a lot of opportunity in the market.  While one of the products at Iron is Docker-based, we use a wide variety of software from many companies with roots in OSS.  We’re happy to pay for a higher level of support and features for OSS software backed by a business.  For other projects, we often donate through Open Collective to help maintainers and small development teams.  Docker’s donation of containerd was a great move and I think it is a project that fits perfectly into CNCF’s charter.

While Docker, Inc is moving upstream, they haven’t at all abandoned its real users;  developers.   We use Docker daily, contribute back when we can, and are optimistic about its trajectory as a business and a product.  Docker, Inc has a lot of room to grow, and in 2018, it will.

* These fields are required.

Webhooks the Right Way™

If you’re a developer, dealing with webhooks is a part of your life. Nowadays almost every subscription service allows for these user-defined callbacks.  For example, when a Lead is added to Salesforce, you may want to have a task that runs in the background to generate more information about the company they work for.  Maybe you want to receive a request from Stripe when a customers payment fails so you can send them dunning emails?  You get the drift.

The most common way to deal with webhooks is adding an endpoint to your application that handles the request and response. There are some benefits to this.  No external dependencies by having all your code in one place for example.  However, the cons usually outweigh the pros.

Common problems handling Webhooks

Application downtime

If your application is down, or in maintenance mode, you won’t be able to accept webhooks.  Most external services will have retries built in but there are many that don’t.  You’d need to be OK with missing data sent from these services.

IronMQ and IronWorker have great uptime
If your application is down, you could lose valuable data
Request queuing

What happens if you have a ton of webhooks from a bunch of different services all coming in at once?  Your application/reverse proxy/etc will probably end up queuing up the requests along with other customer requests.  If your application is customer facing, this could result in a degraded user experience or even full-blown timeouts.

Use IronMQ and IronWorker to prevent bad user experiences
Too many requests to your frontend could result in request queuing and negatively affect the end user experience
Thundering herds and Cache stampedes

Even if you’re able to process all of the webhooks coming in at once, your system is going to feel the effects one way or another.  This could result in unwanted resource spikes (CPU/MEM/IO).  Unless you’re set up to autoscale, bad things could happen to your infrastructure.


IronMQ and IronWorker can help prevent downtime caused by webhooks
Handling webhooks at scale via your application could result in infrastructure issues


At Iron, many of our customers get around these issues by using IronMQ and IronWorker in conjunction.  Since IronMQ is HTTP based, highly available, and built to handle thousands of requests a second, it’s a perfect candidate for receiving webhooks.  One of the great things about IronMQ is that it supports push queues.  When a message is received, it can push its payload to an external HTTP endpoint, to another queue, or even to IronWorker.

IronWorker is a container based enterprise-ready background job processing system that can autoscale up and down transparently.  We have customers processing 100’s of jobs concurrently one minute, while the next minute the number is up in the 100’s of thousands.

The beauty of the IronMQ and IronWorker integration is that IronMQ can push its payloads directly to IronWorker.  Your work is then picked up and worked on immediately (or at a specific date and time if required).  You can have a suite of different workers firing off for different types of webhooks and handling this process transparently.  This is great for a number of reasons.

Handling Webhooks the Right Way

Happy application

Now your application is never involved in the process of handling webhooks.  This all happens outside of your normal application lifecycle.  Your application machines will never have to deal with the excessive load that could deal with infrastructure issues.

Happy users

All the work you need to do to process webhooks now happens in the background and on hardware that your users aren’t interacting with.  This ensures that processing your webhooks won’t affect your user experience.

MQ and Worker to handle Webhooks
Using IronMQ and IronWorker to handle incoming Webhooks

This is a pattern that our customers are pretty happy with, and we’re constantly improving both IronMQ and IronWorker to handle their additional needs. For example, being able to programmatically validate external API signatures and the ability to respond with custom response codes are on our list.  That said, similar to microservices, this level of service abstraction can also introduce its own complexities.  For example, dependency and access management come to mind.  We’ve had long conversations about these topics with our customers and in almost all cases, the pro’s out-weigh the cons.  This approach has been a success and we’re seeing it implemented more and more.

If you have any questions or want to get started with the pattern above, contact us and we’ll be happy to help.

* These fields are required.

AWS EC2: P2 vs P3 instances

Amazon announced its latest generation of general-purpose GPU instances (P3) the other day, almost exactly a year after the launch of its first general-purpose GPU offering (P2).  While the CPU’s on both suites of instance types are similar (both Intel Broadwell Xeon’s), the GPU’s definitely improved.  Note that the P2/P3 instance types are well suited for tasks that have heavy computation needs (Machine Learning, Computational Finance, etc) and that AWS does provide G3 and EG1 instances specifically for graphic intensive applications.

The P2’s sport NVIDIA GK210 GPU’s whereas the P3’s run NVIDIA Tesla V100’s.  Without digging too deep into the GPU internals, the Tesla V100’s are a huge leap forward in design and specifically target the needs of those running computationally intensive machine learning operations.  Tesla V100’s tout “Tensor cores” which increase the performance of floating point computations and the larger of the P3 instance types support NVIDIA’s “NVLINK”, which allow multiple GPU’s to share intermediate results at high speeds.

While the P3’s are more expensive than the P2’s, they fill in the large gaps in on-demand pricing that existed when just the P2’s were available.  That said, if you’re running a ton of heavy GPU computation through EC2, you might find the P3’s that offer NVLink a better fit, and picking them up off the spot market might make a lot of sense (they’re quite expensive).

When the P2’s first came out, Iraklis Mathiopoulos had a great blog post where he ran Hashcat (a popular password “recovery” tool) with GPU support against the largest instance size available… the p2.16xlarge.  Just a few days ago he repeated the test against the largest of the P3 instances, the p3.16xlarge.  If you’ve ever played around with Hashcat on your local machine, you’ll quickly realize how insanely fast one p3.16xlarge can compute.  Iraklis’ test on the p2.16xlarge cranked out 12,275.6 MH/s (million hashes per second) while the p3.16xlarge at 59,971.8 MH/s against SHA-256.  The author’s late 2013 MBP clocks in at a whopping 121.7 MH/s.  The p3.16xlarge instance type is about to get some heavy usage by AWS customers who are concerned with results rather than price.

Of course, the test above is elementary and doesn’t exactly show the benefits on the NVIDIA Tesla V100 vs the NVIDIA GK210 in regard to ML/AI and neural network operations.  We’re currently testing different GPU’s in our Worker product and hope to have some benchmarks we can soon share based on real customer workloads in the ML/AI space.  The performance metrics and graphs that Worker produces will give a great visual on model building/teaching, and we’re excited to share our recent work with our current ML/AI customers.

While most of our ML/AI customers are on-premise, we’ll soon be looking to demonstrate Iron’s integration with P2 and P3 instances for GPU compute in public forums. In the meantime, if you are considering on-premise or hybrid solutions for ML/AI tasks, or looking to integrate the power of GPU compute, reach out and we’d be happy to help find an optimal strategy based on your needs. at The Machine Learning Conference



Attending MLconf in San Francisco on November 10th? If so, come say hello!

We’ve been seeing more and more customers hiring machine learning talent in order to tackle operational efficiencies and hone in on their forecasting. Iron’s platform is helping in almost all phases of the process, from ETL operations helping with the build phase to building models through distributed, hybrid and on-prem, IronWorker deployments.  We’ve never thought of ourselves as a machine learning as a service (MLaaS) company, but we’re apparently getting a lot of traction in the industry which is music to our ears!

The speakers this year are incredible and we’re looking forward to the entire event. From Xavier Amatriain’s background with ML driven medicine to Franziska Bell’s work on uncertainty estimations at Uber, we’re pretty awestruck at the lineup.

The event is being held at the Nikko Hotel in San Francisco on the 10th of November, and you can find more details here:

We’ll be following up with a great recap, so stay tuned.  We hope to see you there!

GPU support in IronWorker

In the past few months, we’ve spoken to quite a few customers that have added Machine Learning (ML) tasks into IronWorker. The problem is, these tasks can take a significant amount of time on a CPU vs a GPU. GPU’s were built to handle the parallelization of complex matrix/vector operations that gaming required, and it so happens that deep learning exercises also have similar requirements.

That said, we thought it was about time to add GPU support to IronWorker. We started with a simple test of doing image recognition via TensorFlow. After hacking the example python script to add the ability to download an image via a URL, we zipped up the script and uploaded it to IronWorker. We went ahead and used the latest Tensorflow docker image.

> zip
> iron worker upload --zip --name classify_image tensorflow/tensorflow:latest-gpu python --image_url ""

In this initial push, we released support for the g2, g3 and p2 GPU instances on AWS. Once we fired off that task, here’s what things look like on our end:

It took about 10 seconds of run time for the image classification via IronWorker using a p2.xlarge instance on AWS. We didn’t have a chance to run this against a non-GPU instance, but we’ll leave that as an exercise for the reader. We’re pretty sure it will take a little longer than 10 seconds! The actual output from the script is as follows:

Found device 0 with properties:
name: Tesla K80
major: 3 minor: 7 memoryClockRate (GHz) 0.8235
pciBusID 0000:00:1e.0
Total memory: 11.17GiB
Free memory: 11.10GiB

Egyptian cat (score = 0.60871)
tabby, tabby cat (score = 0.12714)
lynx, catamount (score = 0.07766)
tiger cat (score = 0.07641)
cougar, puma, catamount, mountain lion, painter, panther, Felis concolor (score = 0.00148)

We’ll be working closely with a few customers in the coming months on some large ML/AI projects, and we’ll post as much as we can on their use cases and resulting benchmarks. As ML becomes more and more prominent in Business Intelligence operations, we’re expecting to see a big increase in GPU usage. If you have any questions about our GPU support, drop us a line and we’d be happy to chat.

Robotics with Iron

We recently sponsored a robotics event in Tokyo held by OnLab, DigitalGarage and Psygig… and, it was awesome.  Also, yes… the course below was an actual course from the event.

The participants were to break into teams, build a drone, implement machine learning techniques, gather and analyze data via Iron, and maneuver their drone across multiple courses.  The teams that finished the courses and displayed the most innovative technical solutions were crowned champion.



The ability to utilize GPU instances and fire up containers that run libraries like Keras and TensorFlow allows for the offloading of heavy computational workloads even in highly dynamic environments.  In the last few months, we’ve been speaking to more and more customers who are using Iron for large ML and AI workloads, often breaking them into distinct types of work units that require different levels of GPU, CPU and memory requirements.

Congratulations to the winners of the contest and all those that participated!  It looked incredibly challenging.  If you have any questions about utilizing GPU’s, machine learning, artificial intelligence, or any other computational heavy lifting jobs using Iron, feel free to contact us at as we’ll be happy to chat.



Full Circle and Ramping up at was recently acquired by Xenon Ventures, a private equity, and venture capital firm. Xenon Ventures is headed by Jonathan Siegel, a serial entrepreneur who has founded many popular software services and has made just as many successful acquisitions.

Here comes the full circle. What may not know, is that Jonathan was’s first customer and investor back in 2010 prior to’s creation. Jonathan was client and friend of the founders’ consulting business prior to and encouraged the founders to transform their consulting service into a product.

In 2011 the first version of IronWorker was launched and the serverless revolution began. After pioneering this space, has grown significantly adding products like IronMQ, IronCache, and our latest development of our Open Source product, IronFunctions. This success is due all of our amazing customers and partners! Thank You!!

New and old faces

You may be seeing a new name fly around a bit as well.  I’ll (Dylan Stamat) be joining as General Manager and moving Iron forward. A little about me: I’ve been a personal friend to the founders, I was a co-founder at RightSignature (, founded one of the first HIPAA compliant companies to run on AWS (, was previously the CTO at a large technology consultancy company (ELC Technologies), a Ruby on Rails contributor, a committer to Ehcache, and a big fan of Erlang and Golang.

You will also see and hear from many other familiar faces at – Roman Kononov, Director of Engineering who has been leading our engineering office in Bishkek, Kyrgyzstan since 2011. Nikesh Shah, Director of Business Development and Marketing, and other various new and old members from our globally distributed teams.

Roman Kononov and Rob Pike (with an awesome jacket) at Gopherfest.

As of now – we’ve added 2 new offices to Iron: one in Las Vegas, Nevada, the other in Tokyo, Japan. We’ve hired new Engineers and Customer Success and are continuing to hire. Let us know if you have any interest in joining our team!

What’s to expect moving forward?

New graphs providing quick ways to visualize historical worker concurrency

The short answer is, things are going to get a lot better.  We’ve been very busy since the acquisition.  There have been a lot of bug fixes, improvements to internal tooling, and we’ve added concurrency graphs to help provide more insight into the system.

Near term, we are committed to continuing and ramping up development in our entire product line. This includes better performance and reliability, a new user interface, granular metrics reporting such as concurrency graphs, streamlining customer support and putting new systems in place to better track feature requests and bug reports, and bug fixes throughout our web applications.

Long term, as it relates to products, we are being guided by 2 core principles:
Open Source, and Hybrid Cloud Deployments.

I’m excited about the future, and getting to know all of you! We will have more exciting news to announce in the coming months.  Please feel to reach out to us and stay tuned!

Dylan Stamat

Top 10 Uses of a Worker System

A worker system is an essential part of any production-scale cloud application. The ability to run tasks asynchronously in the background, process tasks concurrently at scale, or schedule jobs to run on regular schedules is crucial for handling the types of workloads and processing demands common in a distributed application.

At, we’re all about scaling workloads and performing work asynchronously and we hear from our customers on a continuous basis. Almost every customer has a story on how they use the IronWorker platform to get greater agility, eliminate complexity, or just get things done. We wanted to share a number of these examples so that other developers have answers to the simple question “How do I use a worker system?” or “What can I do with a task queue?” Continue reading “Top 10 Uses of a Worker System”

In Books: The San Francisco Fallacy

One of Iron’s original investors, Jonathan Siegel, released a book this week that any entrepreneur (or anybody who’s worked in the bay area) should definitely read.  It’s titled, “The San Francisco Fallacy: The Ten Fallacies That Make Founders Fail“, and Jonathan does an amazing job writing about his personal experiences in the art and science of building businesses.

It just launched yesterday and is being offered for $2.99 this week only (see the link above).  We highly recommend grabbing a copy, and what follows is a great excerpt from the book.  Enjoy!


“It’s all about the tech.”

The Tech Fallacy is perhaps the most pervasive fallacy in the tech world. It is endemic and insidious—perhaps inextricable. It first tripped me up as a teenager in my very first tech venture—but that wasn’t enough to cure me, for I have fallen victim to it often since then.

The Tech Fallacy says it’s all about the tech. Tech is the be-all and end-all of what we do. Get the tech right and the rest will follow.

This belief is deeply, badly wrong—as I first discovered in my teens.

How I Failed as a Pornographer

My first tech business was a kind of online forum. It was called a bulletin board system, where members could chat and share software. It failed.

I launched my second online business two years later. It was another bulletin board system where members could chat and share software. Oh, and they could download porn.

I have my parents to thank for my incipient career as a pornographer. My father bought me my first computer in 1989, during one of his periods of regular employment.

It was an IBM clone with 640 kilobytes of ram and a 20-megabyte hard disk that weighed at least ten pounds. It had less power and memory than today’s inkjet printer.

The PC had a menu of random shareware on it: one of the most popular was called Lena.exe. It was just a grainy, scanned image of a Playboy Bunny (albeit fully clothed). You ran the program, and it pushed the pixels slowly onto the screen. It took minutes to load the full picture.

I soon outgrew the menu on the machine, and then I went exploring. The operating system, MS-DOS 3.0, came with a manual. I read it. I learned every command. I saw that there were things called “batch files.” I broke them open. This broke the computer. I watched it being fixed. I learned how to fix it myself (which was useful, because I kept breaking it). I learned how to write batch files. 

I did regular teardowns of my machine. The pieces were on big chips with big pins and on full-size circuit boards over a foot in length. With two screwdrivers, I could unscrew, unstrap, and pry apart everything but the few capacitors and resistors soldered to the emerald-green, silicon circuit boards.

Computers were so young then that it wasn’t clear to us what could go wrong, or why things broke. Disks would stop working and then work again. Displays wouldn’t display in one mode, but work in another. Reset a switch or copy a file and all would be mysteriously better. When something went wrong, it took laborious practice, by trial and error, to find the source of the problem.

This early digital technology was, in fact, fantastically unpredictable. It seemed magical that it worked at all, and as I developed my understanding of how it did work, my respect for that underlying magic increased.

I got into code. Like Neo learning to watch the Matrix, at first I just saw scrolling screens of ostensibly incomprehensible characters; gradually, I began to see patterns and life in them.

I started to search out greater challenges and discovered the bulletin board system (BBS) – a rudimentary precursor to the Internet. A modem was used to dial into a BBS at the cost of a normal call. The BBS allowed you to create a user profile, message others, chat in forums, download free software (shareware), and play games such as Trade Wars—a cheesy, text-based, space-frigate game.

The bulletin boards were a fertile environment for viruses, which spread easily via shareware. As a result, one of the highly sought early pieces of shareware was McAfee’s Virus Scanner, created by John McAfee in the 1980s.

McAfee uploaded his homemade virus scanner from his home to a local BBS, and it spread.
But McAfee’s shareware was also a currency in itself. If you met someone on a BBS and she mentioned that she had McAfee 2.052, and you had McAfee 2.088, then you had currency to trade with.

The bulletin boards placed tight restrictions on how many files you could download: typically, you had to upload one file to be allowed to download three – ensuring sustainability and growth for the BBS. So if you had some shareware that a BBS didn’t have, that would allow you to download three new pieces of shareware. And you could then use that to get new shareware from other bulletin boards.

But this was a different era of telecommunications, before cell phones. Landline calls within your local area were free, but long-distance calls were expensive. So if the BBS was locally-based, you could dial in for free; if it was further away, the cost would quickly get prohibitive – especially as downloads could take hours.

This created a market for more locally available software—a shareware broker. Local bulletin boards would set up to fill this market gap by downloading shareware from a distant BBS and providing it to local users for a subscription fee.

Most of these subscription bulletin boards provided a minimal free allowance to nonsubscribers, and because there was often more than one BBS within your toll-free zone, it was possible to seek out and trade shareware between boards. It was a classic network effect, with shareware spreading rapidly and efficiently at very low cost.

Then I saw an ad for a BBS in Sacramento that charged $60 per year and had twenty thousand subscribers. I thought I had misread it—$120,000 per year? For running a BBS—that is, for keeping a computer and a modem plugged in?

“I could do that!” I thought. And so I did.

Before long, I was hovering in front of my monitor late into the night, watching users work away on my BBS. In those days, you could see the screen your users saw and what they typed. “Analytics” meant staring at the monitor and watching what they were doing.

 I added a notice to the BBS that came up upon login that said I would accept donations. In June 1991, I got my first check in the post for $20.

I thought it would be the first $20 of $120,000. But it turned out to be one of the only checks I received. And it took me another year, and the onset of puberty, to realize that the distant BBS in Sacramento had another section in its files area—one I hadn’t previously discovered.

This wasn’t freeware. It was photos. Lots and lots and lots of photos. Salacious, compromising, illicit photos. There were even a few with crude, jiggly animations of bits bobbing to and fro.

The clue was in the ad, but I had missed it. I had thought the “XXX” was just some elementary formatting.

I had been duped by my prepubescent naivety. It wasn’t the pleasure of using my BBS that people were willing to pay for; it was an altogether more adult pleasure.

My excitement for the BBS drained. I shut it down and asked my mother to help me find a job. She took me to McDonald’s.

I came home in despair, sat down at the kitchen table, and took up the phone book. This was in the Bay Area, so there were pages of computer companies. I started calling. But I was a kid and nobody took me seriously. I kept calling.

Finally, somebody listened, invited me in for a chat, and eventually offered me a job. The company was called ZOZ Computers. I had cold-called my way right through the phone book.

Months into this first employment, I told my new boss about my BBS failure. I wanted to beat my competitors at their own game.

“What’s stopping you?” he asked.

“I’m too young to buy porn,” I said.

“I’ll buy it for you,” he replied. 

He ordered a set of CDs with porn images. I bought a six-disc CD changer for my computer and had three phone lines installed in my bedroom with modems. My mother was working long hours at the time and didn’t notice.

I had built myself a 386 computer and put my old 286 to work answering the phones. One Saturday in 1993, I announced my new BBS via a $15 ad in the local computer trader paper.
Like sixteen-year-olds all over the United States that weekend, I spent a lot of time in my bedroom because of porn. But I suspect there were few others—if any—whose interest was more entrepreneurial than voyeuristic. Though I was a voyeur too, in a sense—stalking my users as they navigated my BBS.

From the moment the red LED lights on the modems first lit up and the modem started to whir, signaling an incoming call, I was hooked to my screen, fascinated by what those callers were doing. When the lights came on, I felt a surge of pride and accomplishment; when they hung, indicating that the system had crashed, I felt a profound sense of failure. 

Users could get three photos a day for free, limited to ten a month, and they were limited to two hours in total online in a month. If they attempted to exceed that, they’d get a message: subscribe.

In order to become a subscriber, they had to download a pack of documents and sign and return them to me with a check: $35 per year. I remember watching my first pack being downloaded and the buzz of thinking, here comes my first customer.

I was aiming for one thousand subscribers. I had the latest tech, decent design, and a good stock of images. But six weeks later, I had made just over $400.

I had no ability to charge credit cards and was relying on people to send checks. Not having a credit card myself, because I was fifteen, it hadn’t occurred to me that I’d need to process credit cards.

Still, I was giddy with success and wanted to share it. I confided in one of the adults I respected, my mother’s landlord. He told her. She wasn’t so thrilled that her teenage son was a pornographer (and she wasn’t so impressed by the distinction between a pornographer and a pornography trader, either). She told me to shut it down. Between that and the too-slow income stream, I decided not to argue my First Amendment rights. At age sixteen, I’d notched up my second tech failure.

The Tech Fallacy Revisited

Selling porn taught me about the Tech Fallacy. I had believed that building great technology must mean that you’re building a great business. That it was all about the tech.

But selling porn taught me that the raison d’être for any business is to give the customer what he wants. He doesn’t want the tech; he wants what the tech can deliver. The tech is just the means to an end.

I thought I could make money from a well-built-and-run bulletin board system; however, decoding those ads in the computer trader papers with their XXXs made me realize that the market was more interested in the XXX than the BBS.

I love good tech. But I’ve learned to follow the good business. It’s a better path.

Take two rival companies. Each is armed with $1 million in investments. One spends $900,000 on its technology development, with $100,000 reserved for going to market (i.e., customer development, sales, and marketing). The other spends $100,000 on technology and $900,000 on going to market.

Who wins? The market-driven one does. It’s not the better product that wins; it’s the product that best knows how to reach its market.

If a thriving company made you its CEO and you decided to let go of its sales and marketing divisions to focus more on the technology, the board would fire you. But walk into almost any two-year-old funded startup, and you’ll see a growing development team budget and a speck, if any, allotted to sales and marketing.

Imagine an upstart competitor trying to challenge an entrenched leader without a sales and marketing division—it would be like a one-legged man in an ass-kicking contest.

Yet in the startups that I encounter, if the company has a team of ten, there’ll be nine developers and just one person who is business driven. Contrast that with companies that have gone public: you’ll see ninety salespeople for ten developers.

Why is this? Partly, it’s intrinsic. People who love what they do often prefer to do it to the exclusion of other things and may not even realize they’re doing this. Tech companies tend to be founded by people who love tech. A single-minded focus on the tech is to be expected but guarded against.

But it’s also a feature of the zeitgeist—the spirit of the times. This takes us back to the first dot-com era. As we’ll see later, the dot-com bubble was characterized by a focus on the idea to the exclusion of all else—even the tech.

When that bubble burst, it left a bad taste in people’s mouths, especially in the investment community. Tech startups acquired the reputation of being charlatans—all talk, no substance.

This perception created a pendulum swing: today, the emphasis in the startup market is often on developing innovative, hardcore technology, with a consequent failure to consider other crucial (maybe more crucial) aspects of the business.

There is a happy medium. Tech is helping to redefine how the world works—how we work and play, find our soul mates and flings, tell our stories, and hail a ride. Tech is required to catalyze these shifts and disruptions. We all love good tech.

But the winners will be those who build the best businesses, not the best tech.