Last week I posted a draft outline for my planned book on “The Coming Information Age" with a proposed chapter on the "Unbundling of the Job." This is an idea that first occurred to me when I attended a workshop at MIT on Work and Value in the Digital Economy at MIT in late 2012. At the time here is what I wrote:
Do people need jobs or can we deliver what jobs provide some other way and in a potentially unbundled fashion? The “jobs of a job” include income, structure, social connections, meaning, and at least in the US, access to healthcare.
Let me elaborate on this idea here. Whenever I mention the idea of a Basic Income as a way of addressing the impact of technology on the labor market someone will reply “but people have to work!” (usually in an exasperated voice). When you then ask “why?” you get one of the following:
1. Because people need structure in their lives. The benign interpretation of this is a genuine concern about people being bored if they don’t have work. It is more likely though a secular variant of “idle hands make the devil’s work” — a longstanding suspicion that people will be up to no good if they aren’t working.
2. Because people need companionship and communication. It is absolutely the case that historically work was where we spent most of our waking time and was therefore the fulcrum for companionship and communication outside and possibly ahead of the family.
3. Because people need meaning and they get meaning from work. In the US it is common to ask people “what do you do?” to find out what kind of work they do. This is often followed (implicitly) by a conclusion about what kind of person they are based on their work.
4. Because people need healthcare. Thankfully with the Affordable Care Act we have started to unbundle healthcare from the job. By doing so we have moved healthcare into category #5 below.
5. Because people need to pay for food, housing, etc. That last objection is of course what the Basic Income is designed to address. I will write more about the math of that in a world of technological deflation.
None of these are really about work qua work. Rationales 1-3 completely ignore that other activities and networks can also meet those needs. More fundamentally they reflect a view that people are not capable of truly living in freedom, where freedom includes choosing what to spend one’s time on. We have come to hold this limited and pessimistic view as a result of centuries of systems that relied on the control of (most) people’s time and effort first for agrarian and then for industrial production.
In the upcoming posts I will write about alternative ways to address these needs without a traditional job. As a quick preview: people are creative (and will be more so if we change our education system) and will find interesting things to spend their time on. And importantly in an unbundling based on a Basic Income there can and will still be a market for labor — it is just that people will be in a very different bargaining position.
Just as a quick recap. I have argued in Computers and the Return on Capital that having cheaper information flows will in the long run drive the risk free rate of return to the time preference. I then examined how technology is likely reducing time preference for individuals through a variety of different mechanisms. In reply to that post Marc tweeted
And yet tech companies keep raising giant rounds of funding and spitting off huge gushers of cash :-).
That would suggest tech companies need more capital (increased time preference) and that they are producing large returns on capital. The second part of this is I have already addressed, writing that in the short run (some) tech companies will produce huge returns on capital.
Today though I want to dig into the first half of Marc’s reply and examine whether companies generally (and tech cos specifically) are needing more capital and how technology is impacting that in the long run. Here is the TL;DR I will conclude that overall technology acts to reduce time preference for companies as well but that in the short term (some) tech cos are raising larger sums due to potential winner-takes-most dynamics.
As a starting point it is useful to remind ourselves why companies need external capital at all. This was the favorite interview question of one of the first people I worked for after college. Most people answered something along the lines of buying equipment or paying expenses. But the answer he was looking for was more precise: paying for stuff before being paid by customers!
That’s important because one way technology reduces the need for external capital is through the pre-purchase of products by customers as happens on crowd funding sites like Kickstarter and Indiegogo. One way to look at this is that the company is effectively borrowing from its customers (ie getting capital in the form of loans rather than as equity). That, however, is only a semantic point. There is no separate opportunity here for a return on capital for someone who just wants to invest without buying the product.
Now obviously a bunch of companies that have done successfully avoided the need of capital initially through pre-purchase campaigns have gone on to raise lots of traditional equity capital, most notably Oculus VR. I will get back to that point later as it is part of the perceived winner-take-most dynamic. Before that I want to cover several other ways in which technology is reducing the need for capital for companies.
Companies, just like individuals, have less need for capital as technology is making (nearly) everything cheaper. I am typing this on a Macbook Air which gives me a ridiculous amount of compute power and memory by historic standards and yet costs less than $1,000. As I wrote previously, companies can also increasingly substitute technology for labor which as a result of this pressure is also becoming cheaper (at least at the unskilled end of things).
And, in another parallel to individuals, companies too are benefiting from assets becoming shareable and rentable by the minute or even second. Most startups today for instance don’t buy their own hardware. They rent it as they need it, which again reduces the amount of capital that they require. Companies that achieve profitability early on can then rent additional machines out of current income instead of having to raise debt or equity. Our portfolio company Science Exchange is helping to bring this model to lab equipment which demonstrates that this trend is not isolated to computer servers.
If these are the trends, then why are some companies, and in particular tech companies as per Marc’s tweet, raising literally billions of dollars in equity? For starters of course part of the answer is “because they can” meaning that investors are offering this money up even if companies could do without it. To dig a bit deeper though, there is a sense that more markets will have some level of winner-take-all characteristic where the leading company will be 10x, 100x or even more valuable than anyone else. And if that’s the case it would be a great source of time preference, meaning if you can buy your way into that position by spending ahead of revenues it will still be worth it.
I do believe that this argument has merit due to network effects. It is still worthwhile though to remind oneself that some formidable network effects businesses have been built on relatively little capital (eg. Google raised only $25 million of venture capital) and that networks too can be disrupted. That can happen for instance when there is a technological shift or if the network operator is trying to keep too much of the economics of the network for itself (or its investors).
In summary then, I believe that technology largely acts to reduce the time preference of companies, ie reduces their need to raise external capital. The exception to this appear to be winner-take-most dynamics which to the extent that they are real and sustained will lead companies to want to spend significantly ahead of revenues (and investors to want to provide that capital).
In my post on Computers and the Return on Capital I made the point that cheaper and more ubiquitous flows of information will drive the risk free return on capital towards the time preference (assuming that capital can also flow freely). But I didn’t really explain what that meant or how it was determined. Let’s start with an extreme case to illustrate the basic idea. Suppose that everyone everywhere was happy with how much they can spend out of their current income (that includes individuals, companies, governments). In that case the risk free return on capital would be zero as nobody would be interested in having debt or raising equity capital.
For there to be a positive market clearing rate of return on capital it has to be the case that some people or companies or governments want to spend faster today than their income allows and so need to attract capital from those who have capital to lend or invest. Time preference is a catch all for capturing this desire to spend now rather than in the future. The relationship between technology and time preference is complex but I think there is fairly strong reason to believe that over time technology is reducing time preference.
Let’s start with individuals. The major purchases for which individuals tend to borrow include education (biggest outstanding debt in the US today, greater than credit card debt), cars, homes and consumption more generally. We are seeing the beginnings of technology being used to dramatically lower the cost of education, in the extreme by making it available for free as in the case of Khan Academy, EdX, etc. So one way technology can reduce the need for capital is simply by making something a lot less costly. But there is another effect at work here. If I need to get all my education up front I may have to borrow, but if we are moving to lifelong and on-demand education I may be able to pay for it out of current income.
Another way that technology can reduce the need for capital is by making assets shareable. That’s what we are seeing with cars which used to be incredibly inefficiently used assets (standing around idly 95% of the time). Whether it is through car sharing, ride sharing or ultimately driverless cars, technology can help shift from an ownership model (which may require capital) to an on-demand model which can again be paid for out of current income.
As far as general consumption is concerned, technology has been driving down the cost of many products so that more people can purchase them out of current income. Computers themselves are of course a great example of that with smartphones being a computer that almost everyone can afford now (not just here in the US but globally). Known deflation has another impact on time preference: unless you have an immediate need you are more likely to wait as products are getting cheaper and better over time.
The one place where for the time being technology has not yet had an impact is real estate. Many people borrow to buy a home and with urbanization still increasing the cost of homes has been on the rise. There is a great infographic showing the multiple of annual earnings required to buy a home in different parts of the UK with a breakout for London. Technology won’t solve this problem in the near term but (unlike many others) I suspect that we are close to peak urbanization and will in fact see people spreading out more in the future. Probably a subject for another post!
A final impact of technology that is relevant to individual time preference is longer expected lifespan. My desire to get something today rather than say next year or the year after is likely to be lower when I feel I have more time. None of this is saying much though about individual preferences. There will likely always be people who are patient and others who are not.
In an upcoming post I will consider the likely impact of technology on time preference for companies. There too I believe that technology is largely acting to reduce time preference in the long run. So we might get all excited about a future of lower returns on capital and how this might reduce the impact of wealth inequality. That, however, would neglect the potential for external shocks. The one I am thinking of in particular is climate change. There is a scenario in which a lot of capital is required very quickly to deal with say rising sea levels. Time preference would go way up, eg we need a sea wall now, not over the next hundred years. If that were to happen there would be a spike in the returns to capital *if* this is financed by borrowing and investment in privately owned companies and infrastructure.
Since our trip to Africa was a family vacation and I really didn’t want business to intrude I wound up not spending time with startups in Nairobi. But I did talk to a lot of people we encountered about their use of technology.
Mobile communication is almost everywhere. Only when we went into more remote Samburu territory did we not have a cell signal. Many people are still using feature phones but Android is making rapid headway. An iPhone is considered to be a real luxury item and very few people have one. I took a picture of downtown Nairobi that shows a big LG and an even more prominent Samsung ad (admittedly not a great picture so you have to search a bit).
M-Pesa, the mobile payment system, is used incredibly widely. It has had some very positive effects, such as being able to pay women who work directly as is done for example by the Leakey Collection who work with Maasai women. That in turn has had a dramatic impact in reducing domestic violence against women. Somewhat surprisingly though, the use of M-Pesa has not reduced corruption. In fact you can now bribe folks using electronic payment instead of cash and some people think that the added convenience has increased corruption. It seems that there is an important tradeoff between adoption and enforcement. If you started to track electronic transactions on M-Pesa as a way to crack down on corruption you might stunt growth of electronic payments (people would be a lot less likely to use EZ Pass if they got speeding tickets from it).
Another big surprise for me was how relatively underdeveloped solar energy is. In fact the official Kenya government policy we were told is to invest more in grid development and fossil fuels which if true is bizarre at best. Distributed solar generation has huge promise in Africa. Fortunately, there are now startups such as M-Kopa, that are focused on helping finance the acquisition of solar devices. We saw one solar lamp in particular that doubles as a mobile phone charger and is very affordable.
We also went to visit a school that is supported by the Lewa Conservancy. One of our kids had done a small fundraiser prior to our trip and bought school supplies. When I first looked at what he had bought — paper, pencils and other very basic supplies — I thought this couldn’t possibly be what they needed. But it turned out to be spot on. When we went to the school we found it had 640 students and 18 teachers. The classrooms had 30-40 students in them with a teacher and a whiteboard. Basic supplies where exactly what was most needed.
Kenya has apparently announced a one laptop per child initiative. Based on our school visit though it would seem that subsidizing smartphones would be a much better route. Many of the kids walk long distances to school and it seems unlikely that they could carry a laptop back and forth. A phone in fact would make that walk safer. Also phones could have direct cellular data connectivity obviating the need for maintaining a local network. The school could add solar panels for charging the phones.
Overall I came away with a sense of optimism about the potential for Kenya. One of the most interesting questions though is what kind of society a country such as Kenya should be aiming for. I will have more to say about that as I shift my writing on Continuations to focus on my thoughts about the Information Age. I believe there may be an opportunity to leapfrog the industrial model.
And here are the slides, including a final slide with image credits (most images come form flickr are CC licensed):
Looking forward to comments and suggestions. I am planning to expand this material over the coming weeks and months.
Last Tech Tuesday I wrote about how engineering led companies sometimes underrate the importance of marketing and sales. One of the comments on Twitter pointed out that the converse is also often true and I replied that I will write a post about that, so here it goes. Many companies founded by a pure business team tend to struggle with technology and fail to deliver the products or services they envision. There are at least three distinct failure modes that I have seen here over time.
The first are teams that outsource their initial technology development entirely. By this I mean that they don’t have a truly technical person on their own team. This hardly ever works. I am sure people will post examples of successful counter examples but most of the teams I see who fall into this category are struggling mightily. Some of them fail to ever ship a product. Others ship something but it is delayed and a far cry from what they had in mind. Based on lots of experience my clear and unambiguous advice here is: if you don’t have a technical member of your founding team stop everything else you are doing and find somebody (I will have a separate post on how to do this). In many situations you would be better off not continuing at all if you can’t do this and instead take time out to learn enough technology yourself to build an initial version.
The second are teams that add a technical person early on but always treat engineering as a substitutable appendage to the company cycling through many engineering leaders and accumulating massive technical debt along the way. Things may look like they are going well initially, but over time the product development cycle for companies like this starts to slow down dramatically as the technical debt makes innovation harder and harder. Churn in the engineering organization also means that there is less institutional knowledge about why things were built in a certain way to begin with.
The third are teams that bring on board a technologist but then proceed to let that person build an engineering fiefdom that’s disconnected from the rest of the organization. The failure mode here tends to be an over-engineered solution that invests heavily in technological infrastructure before having found product market fit. There may be no technical debt here in the classical sense but it generally won’t matter because many of these companies never really get off the starting blocks.
The root cause in pretty much all of these situations is a lack of understanding of technology. It is unfortunately easy to go through business school and/or work on the business side of startups or large companies without ever developing any meaningful understanding of technology. That, however, is a recipe for mismanaging technology as it will translate into a fear of engaging and an inability to ask the right questions. If that happens to describe you, then you might want to go and read Tech Tuesday from the very beginning.
Today’s Tech Tuesday is a relatively short note on the “Bleeding Edge” — technologies that are even beyond the cutting edge. Every technology tends to start life at the bleeding edge with early releases that are unstable and poorly tested, many different ways of doing something (instead of an agreed upon best way) and with upgrades that are not backward compatible. It is tempting for startups to embrace bleeding edge technology for several reasons: first, you are starting from scratch, so why not use the very latest? Second, if it works out well it can give you a competitive advantage. Third, it can be a recruiting tool for people who want to get on the next technology trend.
Before you adopt the bleeding edge though, make sure you understand the downsides. In the worst case scenario you find yourself sitting on technology that is no longer supported at all. That will leave you with a tough decision between maintaining it yourself or migrating away. Even in the best case though you are likely to face changes that come from the external technology that force you to rewrite your code (because the changes are not backward compatible). There too you face a tough choice — if you stop upgrading you avoid any rewrite but in all likelihood you are not stuck with whatever version you have which at some point (often very soon) will no longer be maintained.
As a general rule then I suggest to folks that unless you absolutely definitively need it, wait to adopt a technology until it has started to settle down a bit with the vendor (or vendors) reasonably firmly established, the number of releases slowing down considerably and — most importantly — a commitment to avoid backwards incompatible changes unless absolutely necessary. The node.js project for instance seems to be settling down (there are drawbacks to this too as people who were hoping for a different module system were quick to point out), but in terms of adoption this is a big plus.
One of the questions asked by a Tech Tuesday reader was about using multiple different programming languages for different parts of a site. Back in the early days of the web that wasn’t really an issue because you would write the page generation in something like Perl or TCL and that was all there was. Well, not really because even then you had to know HTML but of course early HTML was so minimal that it didn’t really matter much.
Having said that, I think the prime directive should be to use the right tool for the job even if that results in multiple languages. The benefits from a proper match will ultimately outweigh the added cognitive and tooling overheads. Also, you should be very suspect of any engineer who has only ever programmed in one language and does not feel comfortable or interested in picking up a new one.
PS Please ask more questions!
PPS Minimal links today but I am running to catch a flight!
The topic fo today’s Tech Tuesday is one that every startup I have ever seen struggles with: what to do about technical debt. First off, what is technical debt? The Wikipedia page explains it as “the eventual consequences of poor or evolving software architecture and software development” which result in more effort for subsequent work.This is actually quite good because it makes clear that technical debt doesn’t just result from mistakes (the “poor” part) but also from “evolving.” And as you may recall my advice has been to startups to evolve their technology as they grow.
The direct corollary from the above is: every startups has technical debt. And I mean every. Show me a startup that doesn’t have it and I will show you a company that has vastly over-invested in engineering relative to their scale and relative to product market fit. So if every startup has it, the question becomes, what should you do about it? The answer here is not unlike what you should do with financial debt: don’t try to pay it all back at once but also don’t ignore it and let it pile up further.
Why not pay it all back at once? First, because often that will result in the temptation to do a complete rewrite, which as I wrote before is a very bad idea. Second, even short of a complete rewrite trying to pay it all back will tend to slow down development of new features or even plain old bug fixing too much relative to the needs of customers (and hence the business). The best way to think of it is that there is some natural level of technical debt that exists at all times.
Of course you shouldn’t ignore technical debt either and especially not let it continue to pile up. If you do that, eventually making any change to the system gets so hard that your product becomes frozen. So instead what you need to do is allocate some fraction of engineering at all times to paying back some technical debt. This is one of the key reasons why your total engineering productivity (as measured from a user visible standpoint) will never be as good a year or two into the life of a startup as it was in the early days.
What is the right fraction? The answer is of course: it depends. But as a broad rule if you are a couple of years into it and you are not spending at least about a third of engineering time on rewriting some code (paying back technical debt) you are probably in denial about the extent of your technical debt. And conversely if you are spending more than two thirds of engineering resources on a sustained basis you are probably being overly aggressive.
If you have great examples of different types of technical debt that you have encountered, I would love to hear them. And of course if/how you managed to deal with them.
I still have quite a few great topics suggested by readers to work off for my Tech Tuesday series on technology in startups. But today I want to take on a different issue because it has been on my mind. I have now been programming computers in one way or another for over thirty years (yikes) and have seen a lot of technologies come and go during that period. So when something new comes along I tend to think of the great French saying: “Plus ça change, plus c’est la même chose” (the more things change the more they stay the same).
One of these constants has been that new technologies all too often wind up being seen as a silver bullet: something you can use to solve a difficult problem (werewolves, server scaling) with a solution that is simple and yet super effective. Unfortunately, technology silver bullets are as mythical as their werewolf counterparts. That’s not to say that we haven’t made progress and that every once in a while something that was previously hard becomes easy (or at least easier) but those are few and far in-between.
For a while recently people were treating node.js as a silver bullett and now it appears to be Go. So you wind up hearing things like “our xyz isn’t scaling so we should rewrite it in Go.” Now for some cases it may well be true that you need to rewrite a portion of what you have and use a tool that gives you more speed. But before you jump from there to the conclusion that you need the silver bullet du jour keep in mind that people have been writing high performance systems for a long time in existing languages.
So almost inevitably the answer is: you need to either restructure your existing team and/or hire some new folks. When you do that beware of anyone claiming to be an expert in a specific language or technology, especially one that is less than a decade old. If you need say a super low latency in memory server find someone who has written a bunch of those in whatever language rather than a self-declared expert in node or Go.
PS I spent a couple of hours over the weekend looking at Go and it does indeed seem like a promising alternative for situations in which you might have previously resorted to C or C++.