Sunday, June 16, 2019
I’ve written a bit about mishandled change attempts — everyone loves a little schadenfreude, and failure is easier to spot than success.
This does not mean I think it’s wrong to change: you can’t keep selling buggy whips or spellcheckers when the market for them disappears. Let’s set aside the strategic question of recognizing that the need for change is there: it’s somewhat data driven and somewhat emotional and a huge topic on its own. But tactically speaking, once the decision is made, how to proceed?
First, an inflection point must be identified. Can the current business remain profitable long enough to keep the company alive while the new business starts up? If yes, then you’re planning for a relatively smooth transition. The new business takes off, the old business lands, management feels profound relief and it’s high-fives all around.
Product: If your company can gradually transition into a new form, then launching new products is a great way to get there. The most obvious example of transformation via product is Apple. Famously vertical, Apple has gradually shifted from computers to music players to compute appliances, but always from the same brand and always offering the same core value proposition. Amazon Web Services appears to be on a similar trajectory. If their original business of rented server instances sunsets in favor of pure server-less, it would be a smooth transition and represent very little change in the vendor-customer relationship.
Business unit: If a more intense change is needed, you may need to start the new business as a separate vertical unit. Microsoft has been fairly successful at this with Azure, while many others have done worse (such as Intel Online Services). A business unit is ideally a separate business. Some fail to actually separate, and remain dependent on the parent until they fold back in. Some fail because they blatantly compete with the parent instead of outside challengers. A successful business unit helps its parent to produce a new business. Azure is a good example of this — it enables Microsoft to continue selling the same value chain into a changing enterprise marketplace. The same approach can be seen in enterprise software companies that sell their products as a managed service, such as Atlassian.
If the window for change is too short though, and the company can’t survive on existing products, then you’re planning for a rough ride. “Any landing you walk away from is a good one” in this case. Company wide transformations mean stopping the old business and starting a new one. There are not a lot of examples of success, but one really stands out: Netflix pulled this off, after a nasty misstep. Good luck if this is your situation, I’d love to hear of another success!
Wednesday, June 12, 2019
If you’ve built a monolithic enterprise product, it is not sensible to convert it to multi-tenancy. You can sell a managed service provider (MSP), but you’re not going to get to software as a service (SaaS).
Often no one wants to discuss reasoning at all, because the need to convert your business to a different model is taken as an imperative which overrides any reasoning. Present problems are ignored, because the future state is too valuable to ignore. Unfortunately, “skating to the puck” in this case is leaving the rink, and the result looks like disrupting yourself.
But what about customers who demand multi-tenancy? There are very few customers who actually need multi-tenancy features. Let’s take a moment to clarify what these features are, because a lot of folks confuse multi-tenancy with role-based access control (RBAC).
Multi-tenancy lets you operate a single instance of a product for multiple groups of people, keeping content, capabilities, and configurations hidden from users who aren’t members of the correct group. Multi-tenancy features allow for a super administrator who can configure which tenants are part of which environments. They allow for tenant administrators who can configure which users and groups are part of a single tenant. They allow for tenant users who do the job that the software is for.
Most customers do not need multi-tenancy features for themselves, they need to be tenants and they hope that the vendor is using modern cloud techniques to deliver features cheaply. Maybe they want administrivia to be separated or hidden away so that the result is delivered as a service. This doesn’t mean the customer wants multi-tenancy. It means the customer wants your software as a service.
The exception is the customer who plans to provide your software to their own customers as a service. This customer does want multi-tenancy features: they want to manage the access rights of business units A, B, and C. This customer is not going to be happy with a stack of singleton instances of the software. This customer needs a professional services development partner, or perhaps a different software vendor. They are asking the vendor to sell a product that allows configuration and maintenance of a multi-tenant environment.
The whole conversation rests on an assumption that the resulting software environment will be simpler and cheaper to set up and use than a stack of singleton instances. I see no evidence for that assumption when the software in question was not designed from the ground up as a multi-tenant application. It’s far better for the vendor to offer their software in singleton mode as a managed service. This effort will inevitably produce the tools necessary to support and automate software installs, which the company can decide to sell to selected customers if they like; but those tools do not need to be exposed to all customers.
Sunday, June 2, 2019
Open source community incentives are biased to prefer developers over content creators.
Open source communities are particularly prone to this failure mode. After all, the developers in the community are all doing their work for valid reasons, so why wouldn’t content creators join them? Hot take: the incentives are different.
Open source development is a resume-building value add for the developer. They’re publishing concrete proof of their ability to write working code. In some cases that code even solves interesting problems. In the best cases the developer is proving that they can work in a distributed team.
This effect continues for a dedicated developer writing content, but that developer isn’t always in a good position to write content without the help of customer-facing consultants, engineers, and analysts.
The social reward of providing quality content is not the same for a developer as that for providing quality code. You might think this is driven by a technical difference. Isn’t writing a configuration file or a test file easier than solving an engineering problem in a compiled language?
Well, maybe. For instance, writing content that reliably and optimally finds all of the vulnerable Java engines across an entire organization is far harder than any whiteboard coding test. (Hint one: a JRE doesn’t have to be registered with the operating system in order to operate. Hint two: crawling the file system is very costly. Hint three: you can’t rely on OS indexing features being enabled.)
Worse, the risk level is higher for the developer writing content: the content is an incomplete starting point, the user has to learn more to be successful, and the failure potential is increased. So the developer’s risk-reward ratio is skewed away from writing content and towards writing engines.
What about professional service consultants? Don’t they spend every billable hour writing content? They sure do, and billable is the key word there. They’ll only release their work to open source when it’s no longer a competitive edge: too commonplace or esoteric to be regularly valuable. Again, misaligned incentives blocking open source content.