I’ve been making my way though the Marine’s Warfighting paper, after finishing Coram’s excellent biography of John Boyd. One of the topics is addressed is the advantage of speed, with this note:

Radical Markets (well worth a read if you haven’t had a chance) offers some unusual ways market dynamics can be introduced to some traditionally very un-marketlike domains. One example is taxes and work: self assessed rates of the value of one’s labor, taxation against that assessment, balanced with a requirement to perform the work for the stated price. There are many practical concerns with this, but it poses an interesting thought experiment!

One of the big questions when building a developer product is what type or size of company to go after, with a particular question mark around large companies. Is targeting enterprise inevitable? A lot of products start for individual developers, small teams, and the long tail.

Last week I had an excellent conversation in Brooklyn around the effects of automation on jobs. One idea I found useful to share was the distinction of High Road and Low Road employers used by Thomas Kochan at MIT Sloan. The two roads are between employers who provide a supportive environment for employees, and ones who treat employees as a cost to minimise. The examples used are often Wal-Mart (on the low side), and Costco or Market Basket (on the high).

In the dark and distant past I used to give talks on search. I had an interest in information retrieval generally and drifted into some of the popular libraries and services of the time. One popular choice was Solr which is based on the Lucene library. I also tried, and was impressed with, Elasticsearch: a newer Lucene based tool, but with a much easier to use API.

Running a developer product or a developer relations team means making trade-offs about where to invest time, money, or focus. Being able to attach values to developers can make conversations easier across different business functions, and allow more direct apples to apples comparisons of things like the potential value of activities.

Developer services are an umbrella term for any kind of pay-per-usage developer product, usually provided as a hosted service. The majority of AWS, Google Cloud and Azure services fall into this bucket, as do numerous others. It is a relatively simple model, pay for what you use, but it has a host of challenges to building a great, sustainable business.

In this post, developer platforms means multi-sided markets where one of the sides consists of software developers. Platform businesses are immensely powerful drivers of the modern tech landscape— pretty much every notable tech company has at least some aspect of a platform business in their DNA.

Thinking about developer products means thinking about developers. What is different about software development as compared to other professions or interest groups? In particular, what needs to be considered when building tools and services for developers?

DevRel, developer advocacy or developer evangelism teams are a part of almost every recent developer-services success. Many DevRel people are hired for their functional responsibilities (we need someone to do X), rather than how they fit into the business.