Analysing For The Long Term

There are a lot of tech company earnings announcements this week.

For those unfamiliar, every three months publicly listed companies publish financial statements (their 10-Q in the USA). This is a legislated requirement, and there is certain information they have to contain, one part of which is how much money they got paid, i.e. earnings.

The companies generally accompany this legal requirement with the not legally required press release and a phonecall or webinar where financial analysts get to ask a few, often mind-numbingly inane, questions.

I, largely, don’t care.

My Day Job

I’m a tech analyst and consultant. I do not advise day-traders on whether they should buy a few million dollars of Microsoft stock and then sell it immediately after the earnings announcement because Azure made its numbers or not. I find that boring.

My job involves advising vendors and customers on strategic decisions that generally have implications for very large amounts of money and years-long time-frames. The day-to-day movements in the stock market caused by largely uninformed speculators don’t matter much for these kinds of decisions. Trying to ascribe motivations to the daily random walk of stock prices is basically astrology for men in suits and it is not for me. I don’t think you should run a government or economy on astrological predictions either, but apparently this is a minority view.

But I digress.

Keeping Things Alive Is Hard

Part of the reason for the lengthy time-frames is inherent to the nature of the stuff I advise on: building a startup from seed stage through to scaling out; product portfolio design; buying, installing, and running tens of millions of dollars of enterprise technology. None of these happen overnight, and change is relatively slow.

It might feel fast, but that’s because you’re comparing it to other, even slower moving things. Most things, most of the time, don’t change very much. Stable systems don’t change very much because that’s what stable means.

I am mostly concerned with the long-term operations of things that are successful, not building stuff in a weekend that instantly fails and gets abandoned. Things that work stick around, and mostly the things that stick around are the things that didn’t die from making fatal mistakes. A lot of my job entails trying to get people to avoid obvious mistakes that other people already made and they don’t need to repeat, with varying degrees of success.

And sure, you might run a product experiment in a cloud over a few weeks and decide that, yes, this thing is actually valuable to customers and we should turn in into a production thing that we keep around. That’s great! But that’s the point at which things get more complicated, because now you need a lot of boring stuff you don’t need for a throwaway prototype, like reliable storage and backups and access control and audit logs and online-upgrades and scalability and on and on.

“Keep it alive” hard is different to “barely working” hard. Many problems are difficult to solve in the first place, it’s true, but entropy is a fundamental constraint of the universe we inhabit. Keeping something alive means working against entropy not just once, but constantly, every day, forever. It has a kind of constantly changing, self-referential systemic complexity that I find much more interesting than betting on whether or not the line will go up tomorrow.

It is why I do what I do in the way that I do it.

Bookmark the permalink.

Comments are closed.