Be in a business

It makes for better cocktail party conversation

(Like this article? Read more Wednesday Wisdom!)

One of my former interns wants to do a startup, but she has a problem: She has a deep well of technical knowledge and lots of experience running infrastructure, but she has no experience in any particular business. And I don't mean that she doesn't know how to do capitalization tables or how to hire; what I mean is that she has no experience using computers to solve actual problems that normal people or companies have.

I spent about half of my career (so far) in big tech, solving complex technical problems. It was fun, it was interesting, but also disconnected from reality. I know incredible amounts of stuff on how distributed key/value stores work, how to run batch jobs effectively on huge amounts of data, how to build a high capacity, low latency, web service, and how to monitor all of that effectively. That's all critical knowledge if you want to keep a cloud service running, but it does not help me at all solving someone's business problem, unless that problem is keeping a cloud service running, and there are only a handful of companies in the world that do that.

When I was on Google Flights, we had regular talks with the airlines that used our flight search engine. During one of these talks, the CEO of one of the big US airlines said the something interesting: “Our goal and core competence is not running data centers or complex IT systems; our core competence is the safe transportation of passengers”. That might seem obvious, but it bears a little bit of reflection: That's what their customers pay them for! Not for how well they could integrate with our QA environment or if they could build a continuous deployment system to match our release schedule. It’s important, but it’s secondary, or maybe even tertiary, to their core business. If their integration with Google Flights goes down, that’s very costly, inconvenient and will make the newspapers. But it’s nothing compared to what will happen if one of their planes goes down. If you are really going to help them, will you sell them a data streaming solution, or will you make their planes safer? And what are they more likely to be interested in and pay money for?

Cue jokes about the 737 MAX :-)

I come across many startups that do cool and fun technical things but that do not solve an actual business problem of a potential customer. That’s not to say they don’t do something useful, but to potential customers it’s probably even money if they should use their service or not; they might provide a good service, but they’re not essential to their customer’s business. There's still money in there (like in the banana stand), but they are not offering huge value to the bottom line of their customers and that makes them vulnerable. 

If you are selling a product to your customer, are you critical to their business, or are you a convenience, a minor cost saving, or just luxury? All things considered and in the interest of a steady income stream, I’d rather be critical to my customer’s business.

For instance, one startup I looked at some time ago had technology to automatically generate a GraphQL API on top of an existing database. Cool widget, and if you need to provide one of these APIs on top of your database, definitely something worth looking at. But a feature like that plays an important role only in the corner of a corner of a project in a business. It is the high tech equivalent of providing the paper cups to a music festival.

I came to think of this topic through a conversation with another friend who also wants to start a business but who figured out that he has no clue what companies actually do or how they operate. He spent years in the tech industry solving interesting networking problems, but he realized that he doesn’t know the first thing about what customers do with his networking tech. Of course it is cool that you can shuffle bits around, but what do these bits actually represent? And isn’t there more value to be had being in the bits than in transporting the bits?

After talking to these two friends I came to value my time as a consultant, supporting businesses with the tech side of business problems, as it gave me a good insight in what companies actually do and need.

During my undergrad I had a side gig with a software company in Rotterdam that created PC software to support pension advisers. Technically speaking this was simple stuff: A desktop application with a few forms, a database with customer information, some actuarial math, and of course the inevitable reports. Technically speaking there was not much to write home about. At one point, Arthur, our head of software development, was in meetings with the math people of a large insurance company about changes to the software for their particular products. I was surprised to see that during these meetings, Arthur could hold his own when talking to the insurance company's actuarians when talking about how to do the underlying math and how to construct these tables. This was an eye opener for me. Apparently in order to write successful pension software, you need to know a lot about how pensions work! Stunning insight, I know, but I was 21 or so with zero experience. It was formative.

Fifteen years later, I was at a bank working on software for high value international payments and zero balancing. This is a world where terms like book balance, intraday balance, MT940, and MT942 play a role. After a while I figured out that our testers didn't understand any of this. Consequently they were constantly flagging problems because they expected two numbers to be the same where they shouldn't and overlooking problems where two numbers were the same but shouldn't. I responded by writing a document called "Balances for Dummies”, where I explained that modern banking does not work like Gringotts, with lots of vaults where all your money is stored. Instead, your account value is the result of a constant stream of settlements between you and the bank, and depending on how you process that stream that value might be different. So if you shoot a new transaction into that stream that is not yet booked into the bank's ledger, your future available value balance changes, but your book balance doesn't.

These insights helped me greatly when I enrolled in law school and learned how bank deposits and withdrawals are handled during bankruptcy.

Unless you are a pure tech business, tech is subservient to the business. And even if you are a tech business, your tech better eventually support a business. The only reason a normal (non-tech) company has or uses technology at all is to support the business. If you want to make money in that world, you have to understand that business. Even when you are squarely on the tech side of a business, understanding that business will allow you to set the right SLOs and make the right risk tradeoffs. For that reason, whenever I was working as a consultant, I always asked what the business function was of the systems that I was working on.

Fun but slightly unrelated side story: In the late 1990s, when the Internet was starting to happen, I was doing some consulting for the Dutch Ministry of Foreign Affairs. At some point I was hanging around because my point of contact needed to find a console cable for the Cisco Internet router where I needed to type in some arcane commands in order to make the DNS work or something like that. While loitering, I saw two people bent over a keyboard and peering at the screen. From the commands they tried to enter I gauged that they were trying (and failing) to recover some files from a tape backup on the HP9000 server that was under their desk. At that time I was regularly teaching HP-UX system administrator courses at the HP Education Center, so I thought I might be able to help them. I ascertained what they were trying to do and then dictated the correct frecover command.

As the files were coming back from tape I asked them two things:

1. How had these files gone missing in the first place?

2. What is the business function of this machine?

The answer to the first question was that they had done an “ls" and found a file in the directory called "*", which they of course had tried to remove with "rm *" :-) The answer to the second question was that this was the X.400 email server for the Organization for Security and Cooperation in Europe. Let this sink in a bit: The mail server through which the governments of the US, Russia, Germany, et cetera were exchanging emails was administered by people who removed files called "*" with "rm *".

I came back two weeks later for some more tweaking of the router and I saw these same two guys, but now they had a book called Unix For Dummies lying next to the keyboard :-)

Knowing the business is of the essence if you want to be effective supporting that business with technology. Whenever you are trying to sell something to someone, you are much better off if you sell something that they need and they know that they need it.

There are a surprising amount of tech businesses out there that sell the solution to a problem that the customer doesn't know they have and that can also be solved in other ways. That’s an uphill battle because first you need to convince the customer that they have a problem and then you have to sell them your solution. You now have two hurdles to take and the first one is massive. The customer might not know that they have this problem or they might not care enough because their current solution works for them (albeit maybe suboptimally). Even if you succeed at convincing them that they have the problem you want to solve for them, they might go talk to your competitor. These tech businesses see themselves faced with having to create/grow the entire market for them (and their competitors!) as well as serving it.

If you want to start a business, find a problem that people have and are willing to pay money for to have it solved. That's why Internet payment firms have been so incredibly successful. Every online business in the world has a problem getting paid. If you solve that, you're in business.

So get out of your tech bubble, talk to actual businesses about their actual problems that they are experiencing and then figure out an innovative way of solving it using technology. To do that you will have to become an expert at some business, but that can be fun and rewarding in and of itself. On top of that, it also makes for better cocktail party conversations about what you do for a living.